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Zusammenfassung 

Forth hat keine Standard-Bibliotheken und die Hardware ist nicht 
compiler-friendly. Das macht Forth zu einer Toy-Language. Man kann 
damit keine groBeren Projekte realisieren und fur die Robotik ist Forth 
ungeeignet. Will man in Forth programmieren, fallen extrem hohe 
Kosten an. 
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1 Einleitung 

1.1 Wozu Forth? 

Anfangs war ich etwas skeptisch was Forth angeht. Als ich die 
Sprache und die dazugehorigen Anleitungen das erste Mai gesehen 
habe, wusste ich sofort: das ist nichts fur mich. Jeder, der Forth das 
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erste Mai sieht muss es hassen. Es ist einfach zu sondernbar, zu um- 
standlich in der Benutzung als das man sich freiwillig naher damit au- 
seinandersetzt. Doch irgendwie ist es nicht dabei geblieben, sondern 
irgendwann wollte ich dann doch wissen wie das genau geht. 

Aber was genau ist Forth eigentlich? Am ehesten kann man es 
fur Neueinsteiger so erklaren, dass man es anhand von klassischen 
Programmiersprachen, klassischen CPUs und klassischen Compilern 
angeht. Wenn man ein Programm in C schreibt, jagd man es an- 
schlieGend durch den Compiler, der macht daraus Maschinencode 
und dieser wird auf der CPU ausgefuhrt. C gilt als sehr effiziente 
Sprache, der damit erzeugte Machinencode ist nahe dran am Opti- 
mium. Und hier kommt Forth ins Spiel. Forth liegt genau zwischen C 
und Maschinenopcodes. Es ist eine Art von Makroassembler, nur urn 
einiges machtiger. Was das heiBt kann man am besten erklaren wenn 
man ein C Programm auf einem Commodore 64 zum laufen brin- 
gen mochte. Das ist deshalb so interessant weil auf dem C-64 eben 
kein Linux lauft und auch kein GCC Compiler. Das ubliche Vorgehen 
dafur geht so, dass man auf einem normalen PC das Programm mit- 
tels Crosscompiler in Maschinencode ubersetzt und diese Assembler- 
Datei dann auf dem C-64 ausfuhrt. Man braucht also neben dem C-64 
noch einen vollwertigen Computer wo der eigentliche Compiler drauf 
ist. 

Forth hingegen bringt seinen eigenen Compiler mit. Es ist so eine 
Art von Entwicklungsumgebung die eine Bash und eine Programmier- 
sprache beinhaltet und auf jedem Kleincomputer ausgefuhrt werden 
kann. Viele C-64 User werden mit Assemblern schon Bekanntschaft 
gemacht haben, neben BASIC war das die wichtigste Sprache und 
ublicherweise wurden Assembler auf dem C-64 direkt ausgefuhrt. Der 
Nachteil wenn man direkt in Assembler programmiert besteht darin, 
dass man das komplette Programm darin schreiben muss. Man fangt 
in Zeile 1 mit Mnemonic wie LDA zu arbeiten und die letzte Zeile ist 
ebenfalls nach diesem Raster aufgebaut. Das ist zwar moglich, aber 
umstandlich. Bei Forth hingegen arbeitet man nach dem Bootstrap¬ 
ping Verfahren. Damit ist gemeint, dass man zuerst einmal das Forth 
an den C-64 anpasst, also ein Mapping herstellt zwischen den Forth 
Standard-Befehlen und den MOS 6502 Opcode. Jetzt braucht man 
schon nicht mehr LDA #irgendwas hinzuschreiben sondern kann in 
einer Forth Plochsprache programmieren. Aber, von Plause aus ist 
Forth nicht besonders machtig. Beispielsweise fehlt eine Funktion urn 
Arrays zu verwalten. Aber auch das ist kein Problem, weil man das 
Forth urn diese Funktion nachrustet. Wie das geht erlautert 1 Dort ist 
erklart wie man Arrays anlegt und daraus einen neuen Befehl macht. 
Die Idee ist es, das Forth zu erweitern, bis man am Ende unter Forth 
ahnlich komfortabel programmieren kann wie in Python. Wohlge- 
merkt, ohne dass man dafur dezidierte C-Compiler oder Betrieb- 
ssysteme benotigt. Sondern ein simples Standard-Forth plus selbst- 
programmierte Erweiterungen sind alles was man benotigt. 

Forth zeichnet sich durch einen extremen Minimalismus aus. Am 
ehesten kann man die Sprache mit Brainfuck vergleichen, nur mit dem 
Unterschied das Forth erweiterbar ist. In seiner Grundfunktion kann 
Forth beispielsweise keine Objekte verwalten. Was Forth jedoch kann 
ist auf den RAM zugreifen. Also einzelne Werte auslesen und Spe- 
ichern. Daraus kann man sich selber seine eigene OOP Erweiterung 
bauen. Das klingt jetzt erstmal aufwendig, aber man braucht dafur er- 
staunlich wenig Lines of Code. Und das macht die Faszination des 
ganzen aus. Anders als bei Linux gibt es keine POSIX Standards, es 
gibt auch keine C99 Standards, sondern man muss sich das Forth so 
komfortabel oder so puristisch einrichten wie man es benotigt. 

Objektiv betrachtet macht Forth keinen Sinn, weil man mit Python 
sehr viel schnellere Ergebnisse erzielt. Wer einfach nur ein kleines 
Programm schreiben will, der ist mit Python besser aufgehoben. Forth 
jedoch bietet Vorteile wenn man sich fur Computer interessiert, und 

1 https://learnxinyminutes.com/docs/forth/ 


grundsatzlich etwas daruber lernen mochte. Bei Python und den 
meisten anderen Plochsprachen ist die eigentliche Funktion sehr gut 
versteckt. Den Python Interpreter hat jemand geschrieben, und der 
Python Interpreter wiederum wurde mit einem C-Compiler nach As¬ 
sembler konvertiert, den wiederum ein anderer geschrieben usw. usw. 
Bei Forth hingegen ist man direkt auf der Plardware, und wem das 
nicht Lowlevel genug ist, kann sich in VHDL seinen eigenen FPGA 
Prozessor bauen. 

Die Linux OpenSource Bewegung ist bereits relativ Hacking- 
orientiert eingestelt, indem Sinne dass es eine kutlurelle Ubereinkunft 
gibt, keine propritare Software von Microsoft oder Borland einzuset- 
zen und man stattdessen seinen eigenen Kernel und seinen eigenen 
Compiler verwendet. Aber, Linux kopiert nur das vorhandene Okosys- 
tem, es macht das selbe was auch Unix und Windows tun, nur eben 
mit freiem Sourcecode. Forth geht einen Schritt weiter. Forth bezieht 
die Hardware mit ein und verfolgt einen konsquenten Minimalismus. 
Das heiBt, es gibt uberhaupt keine Geheimnisse mehr, Forther wis¬ 
sen alles. Oder zumindest ist das der Anspruch den die Community 
verfolgt. 

Fur die ersten Gehversuche wurde ich von den meisten Forth Im- 
plementierungen wie gforth, Jonesforth oder Fig-forth abraten und 
stattdessen das Online-Portal Repl.it 2 empfehlen. Man erhalt dort 
einen Forth Interpreter in Javascript, braucht bei sich nichts zu in- 
stallieren und kann die meisten Beispiele damit ausfuhren. Begleit- 
end dazu empfehle ich eine kleine Textdatei anzulegen “Forthhand- 
buch.txt”, in die man wichtige Befehle die man gerade gelernt notiert. 
Anders als bei normalen Programmiersprachen und normalen Be- 
triebssystemen kann man bei Forth nichts herunterladen und das auf 
seiner Festplatte installieren, sondern im wesentlichen ist Forth ein 
Bildungsinhalt, also was man lernen und anwenden muss. Die Idee 
ist folgende: nach einem Atomangriff der einen EMP Blitz beinhaltete 
sind samtliche Festplatten geloscht und auch alle Kopien des Lin¬ 
ux Betriebssystems vernichtet. Propritare Microsoft-Software gibt es 
auch keine. Jetzt sind die Forth Leute in ihrem Element. Sie holen ihre 
Notizen aus dem Schrank, tippen die Forth Kommandos auf eigens 
konstruierten PCs ein und booten damit nicht einfach die Maschine 
sondern beim Booten schreiben sie on-the-fly auch gleich die kom¬ 
plette Software. Sie entfalten damit die komplette Betriebssystem- 
Software, alles was man braucht urn Spiele zu spielen, Datenkom- 
munikation zu betreiben oder Berechnungen durchzufuhren. Das geht 
mit Linux nicht, dort braucht man zumindest den Sourcecode der bei 
einem aktuellen Fedora rund 10 Gigabyte betragt. Sowas kann man 
schlecht ausdrucken. 

1.2 Das erste Forth Programm 

Anstatt dem ublichen Forth Style zu pflegen und komplett unver- 
standlichen Code zu schreiben, mochte ich als Einfuhrungsbeispiel 
ein kleines Programm vorstellen, was gut lesbar ist. Es funktioniert 
nach dem gebrauchlichen Eingabe->Verarbeitung->Ausgabe Scheme 
und ist in Forth ausfuhrbar. Leider ist Lyx nicht in der Lage Forth- 
Syntax korrekt zu formatieren, so dass es als Nur-Text erscheint. 

Auf den ersten Blick ist das ganze nichts besonderes, der Aufbau 
erinnert an ein C-Programm bei dem irgendwas fehlt. Dieses etwas ist 
die Infixnotation, das man also normalerweise schreibt: 

print f C/.d, number) 

Diese Moglichkeit gibt es bei Forth leider nicht. Stattdessen lauft 
alles uber den imaginaren Stack, den man sich als eine Art von 
Candyautomat vorstellen kann, bei dem man oben etwas drauflegt 
und dort auch wieder herunternehmen muss. Dennoch hat Forth 
gegenuber C einen gewaltigen Vorteil: es lauft uberall. Den obigen 

2 https://repl.it/languages/forth 
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variable number 
: input 

. " Please enter a number: " 

23 number ! 

number 0 . cr \ get number and print 

: calculation 

number @ \ get number 

100 + \ add 100 

number ! \ store number to memory 

I add 100 to your number" cr \ tell what i’m 
doing 

: output 

." Output = " 

number @ \ get number 

. cr \ print to console 

thanks for using Forth" 

: main 
input 

calculation 

output 

main 

Abbildung 1: Hello World in Forth 

Sourcecode kann man sowohl unter Linux, Windows und sogar auf 
einem C-64 ausfuhren. Er braucht nicht in Machinenopcodes uber- 
setzt werden, und man braucht auch keine Python-Interpreter Oder 
virtuelle Maschinen. Das ist bei Forth alles schon eingebaut. Das 
klingt zunachst etwas ungewohnt, aber es ist die Zukunft. 

Doch gehen wir das Programm im Detail durch. Was es tut ist 
selbsterklarend, man kann es aus dem Sourcecode ablesen. Das 
eigentlich interessante ist das, was es nicht macht. Genauer gesagt 
wirkt die fehlende Infix Notation auf den Einsteiger irrtierend. Er sieht 
das Programm, aber er kann damit nichts anfangen. Weil, die Main- 
funktion ubergibt keine Parameter. Nun gut, auch in C gibt es Funktio- 
nen die ohne Parameter aufgerufen werden, weil sie entweder globale 
Variablen verwenden oder wie in C++ auf Methoden der selben Klasse 
zugreifen. Nur, es gibt in Forth auch sonst keine Funktionen die Pa¬ 
rameter verwenden. Auch das Word, was etwas auf den Bildschirm 
ausgibt kommt ohne Parameter aus. Stattdessen lauft im Hintergrund 
etwas anderes mit: der Stack. 

1.3 Der Forth Interpreter 

Bisher wurde unterstellt, dass eine lauffahige Forth Virtual Maschine 
bereits vorliegt. Wenn man sich mit Forth naher beschaftigen will, ist 
es erforderlich, diese in C selber zu programmieren. Oder zumindest 
fertigen Code von github zu nehmen und ihn mittels “gcc forth.c” zu 
kompilieren. Hier 3 gibt es eine Forth Virtual Maschine zum Down¬ 
load sie umfasst nur 27 kb. Wenn man sie kompiliert erhalt man eine 
36 kb groBe “a.out” Datei. Was sie macht kann man ungefahr an- 
hand des Sourcecodes ahnen. Man kann dort eintippen “1 2 + .” und 
sieht dann das Ergebnis. Ferner kann man eigene Words definieren 
und Schleifen ausfOhren. Von der Performance her wurde ich sagen, 
dass das Forth ca. 20x langsamer ist ais gforth. Spannender ist je- 
doch eine andere Frage, und zwar ist das obige Forth eine Virtual 
Maschine welche in C programmiert wurde. Also ein kompletter Com¬ 
puter, vergleichbar mit qemu, na ja fast jedenfalls. Am ehesten kann 

3 https://gist.github.com/lbruder/10007431 


man die Forth Implementierung mit einem Turing-Machine-Simulator 
vergleichen. Wo also die mogilchen Befehle auf ein Minimum reduziert 
sind, so dass man gerade so Programmieren damit kann. 

Ich erwahne eine Forth Virtual Machine deshalb urn etwas uber 
die Geschichte von Forth zu erzahlen. Es wurde Anfang der 1970'er 
Jahre von Charles H Moore und Elizabeth Rather erfunden, zu ein- 
er Zeit ais langst die ersten Computer gab. Die Forth Virtual Mas¬ 
chine war der Versuch in die Vergangenheit zu blicken, also in Soft¬ 
ware das nachzuahmen, was Ende der 1930’er erstmals gebaut wur- 
den, Turiing-machtige Computer. Man kann Forth ais weiterentwick- 
elte Turing-Maschine verstehen. Eine Turing-Maschine ist ein didak- 
tisches Modell urn die Funktionsweise von Computern zu erlautern. 
Es wird meist ein Band plus Schreiblese Kopf verwendet. Damit kann 
man die Grundlagen der Informatik erlautern. Aber, das didaktische 
Konzept Turing-Maschine hat den Nachteil, dass es kein richtiger 
Prozessor ist und auf dem Band gibt es auch keine Bereiche wo man 
Unterprogramme ablegen kann. Forth ist ein wenig detailierter und 
orientiert sich starker an einem richtigen Computer. 

Theoretisch, und das ist eine gute Ubung fur den Neueinsteiger, 
kann man mit dem oben verlinkten Forth eigene kleine Programme 
schreiben. Anders ais bei einem reinem CPU Simulator also einen Al- 
goirthmus eingeben und den ausfuhren. Forth dient also dazu, etwas 
uber Computer zu lernen. Und wenn man nicht nur die Forth Virtu¬ 
al Maschine in C programmiert sondern sie ais FPGA implementiert, 
lernt man zusatzlich noch etwas uber Hardware. 

Aber, genau hier zeigt sich auch was die Schwache von Forth ist. 
Es wurde Anfang der 1970’er erfunden bzw. vorgestellt zu einer Zeit 
ais es bereits Hochsprachen gab. Die Mother of all Demos wurde zwei 
Jahre fruher abgehalten (1968), es gab also bereits Computer mit ein¬ 
er GUI. Forth war also keine weiterentwicklung Oder fur den Produk- 
tiveinsatz gedacht, urn damit Software zu entwickeln, sondern Forth 
war das selbe, was wir heute ais Rasberry PI kennen, eine Lernumge- 
bung damit sich Laien, Interessierte oder wer auch immer spielerisch 
mit der Informatik auseinandersetzen kann. 

Und jetzt der Sprung zuruck in die Gegenwart. Warum fasziniert 
Forth bis heute, wenn es doch schon so alt ist? Der Grund ist, dass 
Forth eine sehr gute Lernumgebung ist. Wenn man etwas uber Com¬ 
piler und Computerhardware lernen mochte sogar die weltweit beste. 
Der Clou ist nicht so sehr das oben veriinkte C-Programm, es ist eher 
banal, und der Clou liegt auch nicht in den zahlreichen anderen Forth 
Implementierungen, sondern das bemerkenswerte entsteht, wenn 
man mit Leuten redet, die sich intensiv mit Forth beschaftigt haben. 
Ublicherweise ist das gleichbedeutend damit, dass sie Computertech- 
nik grundlegend verstanden haben und in Folge dessen so wunder- 
bare Chips entwickeln konnen wie den GA144. Forth ist also primar 
ein Lerninstrument wodurch man Wissen erlangt was genutzt wird urn 
High-End-Hardware zu entwickeln. 

Es geht also nicht wirklich darum, Forth zu verstehen, sondern 
alles andere was mit Informatik zu tun hat. Also Software, Compiler, 
Betriebssysteme, Transistoren usw. Und auf dieser Basis erklart sich 
auch, wie die Forth Community funktioniert. Es geht weniger darum, 
mit Forth etwas sinnvolles anzufangen, sondern die Veroffentlichun- 
gen und Projekte orientieren sich an dem Lernbedarf. Das heiBt, wenn 
jemand wissen mochte, wie man einen Parallelcomputer baut, dann 
wird er das anhand von Forth untersuchen. Er konnte zwar auch eine 
normale Turing-Maschine nehmen und sich vorstellen, dass es da ein 
Band gibt und viele Lesekopfe, aber das Abstraktionsniveau von Forth 
ist besser. Weil man dort adhoc einen kompletten Primzahlalgorith- 
mus implementieren kann. So kann man testen ob das eigene Design 
funktioniert, was man sich uberlegt hat. 
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1.4 Ein Hoch auf Lisp und Forth 

Noch in den 1980’er gehorten LISP und Forth zu den beiden wichtig- 
sten Sprachen. Man setzte sie auf hocheffizienten Stackmachinen 
ein und fuhrte Projekte im Bereich der Kunstlichen Intelligenz durch. 
Wichtige und groBe Projekte waren das, von der die normale Welt 
keine Ahnung hatte. Es gab damals sogar humanoide Roboter die in 
LISP programmiert wurde und zwar auf Workstations die uber Boot¬ 
strapping zuerst ein Forth starteten und dann ein Common-Lisp Be- 
triebssystem. Das waren nicht so Anfanger Maschinen wie sie heute 
verbreitet sind, sondern es war advanced Technologie. Wir reden hier 
nicht uber VLSI Oder 7 nm CPUs wie sie aktuell von Samsung gefer- 
tigt werden, nein damals gab es optische Computer, also die nachste 
Generation an Schaltkreisen welche das Silizium verdrangt haben. 
Die Software in den 1980'er lief ultrastrabil, damit ist gemeint, dass 
das Problem mit den Bugs schon im Jahrzehnt davor gelost wurde 
und ausschlieBlich Metaprogramming eingesetzt wurde. Das fuhrte 
zu sehr zuverlassiger Software die Modellgetrieben entwickelt wurde. 
Nicht so wie die heutige Software, wo Menschen dran rumprogram- 
mieren sondern damals wurde die Software aus First Order Logik- 
Spezifikationen synthesiert und die wiederum wurden durch leistungs- 
fahige Neuronale Netz Supercomputer laufend optimiert. 

Ja so war es damals in den 1980’er Jahren. Damals waren die 
StraBen sauber, das Essen schmeckte und der technische Fortschritt 
war uberall. Es war ein sehr schones erfolgreiches Jahrzehnt, in dem 
die Maschinelle Intelligenz zu ihrer Blute gefuhrt wurde.Man kann sich 
das so vorstellen, dass damals die Ingineure rund 2 Monate braucht- 
en und dann lief das Robot-Control-System in Forth perfekt. Es war 
unglaublich schnell, es war fehlerfrei und der Roboter war in der Lage 
menschliche Sprache zu verstehen. Er konnte sie buchstablich von 
den Lippen ablesen und war von einem Menschen nicht zu unter- 
scheiden. Einige der Roboter wurden sogar mit ins Entwicklungsteam 
eingebunden und verrichteten dort die selben Aufgaben die auch 
Menschen ausfuhrten. Und es funktionierte hervorragend. Niemals 
gab es Probleme mit den Androiden, sie kamen morgens punktlich 
zur Besprechung, arbetieten dann konzentriert bis zum Mittagessen 
durch und waren in den Pausen immer zu einem Smalltalk bereit. So 
wie es in einer idealen Gesellschaft ublich ist wurden Probleme schon 
vor ihrem Entstehen ausgeraumt und Einsicht in die Ablaufe bei alien 
Angestellten gefordert. Der einzelne setzte sich fur sein Team ein und 
das Team profitierte davon. Maschinelle Intelligenz und humanoide 
Intelligenz gingen Pland in Hand und verstarkten sich gegenseitig. 
Es war ein angenehmes Arbeiten mit den allerneuesten Technolo- 
gien. Dazu gehorten fortschrittliche Betriebssysteme, neuartige An- 
imationssoftware, Expertensysteme sowie CAD Programme urn die 
nachste Generation an Hardware zu entwickeln. Auch an bionische 
Implantante auf Basis des Forth Stackprozessors war gedacht. Die 
Verbindung mit dem Hive-Bewusstsein funktionierte reibungslos. 

1.5 Literaturangaben 

Die Literatur zu Forth ist umfangreich. Als Besonderheit muss man 
sagen, dass anders als bei vielen anderen Programmiersprachen der 
GroBteil der Literatur aus den 1980'er Jahren stammt. Auf den Ein- 
steiger wirkt das so, als wenn Forth uberholt ware. Nur, die Paper aus 
dieser Zeit sind bis heute aktuell, ja mehr noch, je mehr Zeit vergeht 
desto interessanter werden sie. Hier eine kurze Auflistung was man 
gelesen haben sollte, urn mitreden zu konnen: 

• Referenzwerk uber die Vorteile von Stackcomputern / aka 
Forthchips, “Stack computers: the new wave" [8], online auf 
https://users.ece. emu. edu/^koopman/stack_computers/index.hti 


• Videoaufzeichnungen von Forth Vortragen auf deutsch naturlich, 
https://wiki.forth-ev.de/doku. php/events:start 

• Videoaufzeichnung der Silicon Valley Forth User group, 
https://www.youtube.com/channel/UC2v6b9814ulA5egk5- 
yHAVw/videos 

• Inhaltsverzeichnis der deutschen Forth Zeitschrift, 
https://wiki.forth-ev.de/doku. php/projects:4dinhalt 

• Online Lexikon mit dem Schwerpunkt Forth und alternative Pro- 
grammierkonzepte, http://wiki.c2.com/ 

• Online Portal Repl.it zum Ausfuhren von Forth Code, 
https://repl.it/languages/forth 

• The Journal of Forth Application and Research, 
http://soton.mpeforth.com/flag/jfar/index.html 

Eine Besonderheit von Forth ist es, dass es keine Gegenstimmen gibt. 
Man wird also keine Literatur finden welche sich kritisch mit Forth au- 
seinandersetzt. Und wenn doch, hat der Autor das Konzept nicht ver- 
standen. Alle, die sich sachlich inhaltlich mit Forth auseinandersetzen 
tun dies mit einer Pro-Forth Haltung. 

2 Programmieren 

2.1 Geschwindigkeit 

Kommen wir jetzt zu einem Thema was fur Neueinsteiger besonders 
aufregend ist, und zwar die Frage der Performance. Die schlechte 
Nachricht vorneweg. Forth ist nicht schneller als C++. In der Mehrzahl 
der Falle ist Forth gegenuber C/C++ sogar langsamer. Die Ursache 
dafur ist, dass ein Forth system nur die selben CPU-Opcodes aufrufen 
kann die auch ein per C++ Compiler erzeugtes Programm aufruft. Und 
da heutige C/C++ Compiler sehr effizienten Maschinencode erstellen 
kann man mit Forth das nicht groBartig verbessern. 

Aber, wenn man in Forth programmiert fallen einem sehr viel mehr 
Moglichkeiten ein, wie man die Hardware und die Software schneller 
macht. Hat man erstmal seinen Primzahlen Algorithmus als Forth- 
Code vorliegen, grubelt man automatisch daruber nach, wie denn die 
dazu passende CPU aussehen mag. Und relativ schnell bemerkt man, 
dass der Flaschenhals nicht so sehr die Software ist, sondern dass 
der Flaschenhals die x86 CPU ist. Verwendet man eine Forth kompat- 
ible CPU wird das selbe Programm sehr viel schneller ausgefuhrt. 

Und wenn man das geschafft hat ist der nachste Schritt die Forth 
CPU mit anderen Forth CPU als Array zu verbinden und eine clock¬ 
less Architektur zu verwenden, wodurch sich weitere Performance- 
Verbesserungen ergeben. Anders ausgedruckt, Forth ist zwar noch 
nicht per se schneller, aber innerhalb des Forth Universum ist man 
eher in der Lage daran etwas zu andern. 

Die Linux und Windows User sind hingegen in ihr System einges- 
perrt. Was der C-Compiler mit ihrem Code macht, darauf haben sie 
keinen Einfluss, und wenn Intel beim nachsten Update keine CPUs 
veroffentlicht die dramatisch schneller sind konnen sie auch nichts 
machen. So entsteht ein Fatalismus, wo man glaubt als normaler Pro- 
grammierer ohnehin nichts verandern zu konnen. Man richtet sich 
stattdessen ein und glaubt es musste so sein, dass ein normaler 
Desktop PC stolze 20 Watt schluckt obwohl er gar nichts rechnet son¬ 
dern nur auf den Userinput wartet. 

Durexforth Wie Forth intern funktioniert kann man am besten an- 
hand von Durexforth 4 erkennen. Durexforth ist zunachst einmal eine 


• Noch ein Werk uber die Geschichte der Stackcomputer, [9] 4 https://github.com/jkotiinski/durexforth 
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.ASM Datei die auf dem C-64 assembliert wird. In dieser ASM Datei 
gibt es verschiedene Unterprogramme. Eines fur Fetch, eines fur 
Store und fur jedes andere Forth Statement ebenfalls. Das jeweilige 
Unterprogramm ist in Assembler geschrieben. Meist enthalt es 4-10 
Assemblerbefehle. Wenn man Durexforth startet und dort dann ein 
Forth Programm startet werden diese Assemblerbefehle ausgefuhrt. 
Das heiBt, die Performance von Durexforth ist vergleichbar mit BA¬ 
SIC, es ist eine langsame Hochsprache die zur Laufzeit interpretiert 
wird. Vermutlich ist die Performance von Durextforth urn den Faktor 
2-3 langsamer als wOrde man mit CC65 ein Programm fur den C-64 
schreiben. Die Performance hangt letzt davon ab, welche Maschinen- 
befehle nacheinander aufgerufen werden. Genau genommen ist Forth 
also eine Virtuelle Maschine, vergleichbar mit der JVM. Es ist ein Kon- 
verter der Forth Code nimmt und ihn fur eine konkrete CPU aufbereit- 
et, daher auch die Verzogerung. 

Ahnlich wie die fehlende Infix Notation ist die fehlende Performance 
von Forth etwas, was irritierend auf Einsteiger wirkt. Dadurch wird et- 
was deutlich, und zwar dass es einen Bias gibt. Die meisten Program- 
mierer haben sich daran gewohnt, dass die CPU einfach da ist und 
funktioniert. Sie sind froh daruber, dass Intel Oder ein anderer Her- 
steller sie liefert und das der Instruction Set vorgegeben ist. Ublicher- 
weise wollen Java Programmierer in Java programmieren und nicht 
in Opcodes einer AMD CPU. Deshalb hat man sich auf Standards 
geeignet. Der MOS 6502 hat klar definierte Opcodes und auch die 
AMD64 Architektur hat feste Opcodes. Forth halt sich nicht an diese 
Regeln, Forth macht etwas eigenes. 

Anders formuliert, durch die fehlende Infix Notation ist Forth schw- 
erer verstandlich, und durch die fehlende Performance sind Forth Pro¬ 
gramme langsamer. Trotzdem ist das aber besser. Weil man als User 
die Kontrolle uber sein System zurOckbekommt. Man ist nicht langer 
abhangig von Linux und man ist nicht abhangig von Intel. 

2.2 Objekt-orientierte Programmierung 

Wie man anhand des Hello World Programs gesehen hat, ist es kom- 
fortabel moglich mit Forth ausfuhrbare Programme zu schreiben. Man 
muss sich zwar etwas umgewohnen aber es funktioniert irgendwie. 
Ganzlich anders sieht es bei der Objektorientierten Programmierung 
aus. Seit Ende der 1980’er sind eine Reihe von Papern erschienen 
in denen OOP fur Forth diskutiert wurde. Manchmal mit abgedruck- 
ten Sourcecode manchmal ohne. Die Schwierigkeit besteht darin, 
dass OOP relativ aufwendig ist zu implementieren. Das ganze ist 
nicht nur ein simples Array was man im Speicher reservert, son- 
dern man benotigt auch Vererbung, Garbage Collection und Uber- 
laden. Bis heute gibt es keine brauchbare Extension fur Forth was 
das Thema zufriedenstellend behandelt. Das heiBt nicht, dass Forth 
und OOP nicht zusammenpassen ganz im Gegenteil. Vielmehr ist hi- 
er noch Raum fur Leute die zeigen wollen was sie draufhaben. Eine 
OOP Erweiterung fur Forth zu programmieren gilt als anspruchsvoll 
wie ergiebig gleichermaBen. 

Einsatzfahig aktuell sinid gerade nochso Structs. Es gibt mehrere 
Beispiele wie man das in Forth realisiert. Man muss im Grunde eine 
kleine Forth Extension Programmieren und hat dann in Forth einen 
Struct vergleichbar wie in C Oder in Python. Aber echte OOP ist das 
nocht nicht. Wer nicht gerade selbst die benotigte Extension pro¬ 
grammieren mochte kann aktuell unter Forth leider keine Objektorien- 
tierte Programmierung verwenden. Er kann zwar manuell viele Words 
definieren aber das ist dann nur so als wenn man in C programmiert. 
Man schreibt also 100 Unterfunktionen, kann die auch aufrufen aber 
es fallt schwer damit groBere Programme zu schreiben. Man darf nicht 
vergessen, dass sich OOP nicht ohne Grund durchgesetzt hat. Es er- 
leichtert die Erstellung von langeren Programmen ungemein. 

Als Nachteil von Forth wurde ich die fehlende OOP-Funktionalitat 


dennoch nicht auslegen. Sondern eher als unerledigte Aufgabe, dass 
jemand der wirklich viel Freizeit hat, sich des Problems annimmt 
und so endlich auch in Forth das realisiert was in Java, Python und 
C# langst Standard ist. Der Grund warum sich bisher noch kein- 
er an diese Aufgabe gewagt hat liegt daran, dass OOP zurecht als 
anspruchsvoll gilt. Auch der C++ Compiler der in Linux verwendet wird 
gilt als anspruchsvoll. Es macht eben einen Unterschied ob man nur 
simples C in Maschinencode ubersetzt Oder ob man das selbe fur 
C++ durchfuhrt. Auch einen Java Compiler bzw. Interpreter ist keine 
leichte Aufgabe, und wenn man das in Forth machen will wird es 
richtig anspruchsvoll. Bislang gibt es nur mehrere gescheiterte Ver- 
suche OOP in Forth zu realisieren. Eine davon ist mini-oop.fs welche 
vorgibt eine objektorientierte Erweiterung zu sein, defakto jedoch 
keine Mehrfachvererbung und keine Stringzuweisung unterstutzt. 

Jetzt gibt es zwei Moglichkeiten damit umzugehen. Entweder man 
leugnet schlichtweg die Notwendigkeit OOP in Forth zu realisieren, 
stellt sich also auf den Standpunkt dass Objekte in einer minimalistis- 
chen Programmiersprache nichts zu suchen haben, Oder man gesteht 
sich selber ein, der Aufgabe nicht gewachsen zu sein und muss notge- 
drungen auf andere Programmiersprachen ausweichen, will man mit 
Klassen arbeiten. Das ganze ist kein Nachteil von Forth, sondern hat 
etwas mit der Forth Community zu tun, also wie gut Forth verstanden 
wurde. 

Auch mein eigenes Fachwisse ist in dieser Hinsicht nicht ausre- 
ichend. Ich kann also an dieser Stelle keine Forth OOP Extension 
anbieten. Das einzige was ich erlautern konnte ware, wie man in 
Forth einen Array befullt und wieder auslieBt, aber das ist nur ein 
kleiner Teil der benotigten Funktionalitat. Was ich jedoch sagen kann 
ist, dass OOP absolut notwendig ist will man groBere Programme 
schreiben. Es ist nicht moglich und sinnvoll auf Objekte zu verzicht- 
en und stattdessen nur mit Methoden zu arbeiten. Ich habe das an 
einem eigenen Projekt ausprobiert. Obwohl der Sourcecode mit 500 
Zeilen noch sehr uberschaubar war, war der Verzicht auf Klassen eine 
Produktititatsbremse. Fur den Computer sind solche Programme kein 
Problem. Ja ohne Klassen lauft der Code sogar effizienter als mit. Nur, 
irgendwer muss den Code schreiben und debuggen und das ist ohne 
OOP nur sehr umstandlich moglich. 

Ich wurde mal schatzen dass in einigen Jahren unter Forth objekto- 
rientiertes Programmieren Einzug halt. Das heiBt irgendwer wird sich 
schon finden, der den notigen Handlungsdruck verspurt und eine Er¬ 
weiterung in die comp.lang.forth Newsgruppe postet die ausreichend 
Funktionalitat bereitstellt. Historisch gesehen durfte die fehlende OOP 
Funktionalitat mit ein Grund gewesen sein, warum sich als Alternative 
zu Fortran damals nicht Forth sondern C++ durchgesetzt hat. 

Ein wenig weiter ist da schon die Sprache Factor. Diese erinnert an 
Forth, beinhaltet aber standardmaBig object-oriented programming. 
Leider ist Factor jedoch nicht so maschinennah wie Forth, sondern ist 
Applikationsorientiert. 

2.3 Forth vs. C++ 

Ein Vergleich zwischen Forth und C++ fallt eindeutig zugunsten von 
Forth aus. Forth ist diejenige Sprache welche effizient ist, C++ ist es 
nicht. Forth ist leicht zu lernen, C++ nicht. Forth kann man auf Mi¬ 
crocontroller portieren, bei C++ geht das nicht. Schauen wir uns als 
abschreckendes Beispiel ein Hello World Programm in C++ an, dann 
sieht man auf den ersten Blick dass C++ nichts taugt. Es werden dort 
Klassen angelegt, was bei Forth aus gutem Grund nicht zum Funk- 
tionsumfang gehort. Desweiteren benotigt man relativ viele Lines of 
Code urn simple Aufgaben zu losen. Man kann den Code entweder 
mit “g++ hello.cpp" ubersetzen oder wer Wert auf hohe Performance 
legt kann auch den “-03” Schalter aktivieren. Dadurch wird die heavy- 
loop in der Sleep Methode beschleunigt ausgefuhrt. 
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#include <iostream> 

using namespace std; 

class Rectangle { 

int width , height ; 
public : 

void set_values (int,int); 

int area() {return width*height;} 

void sleep(); 

>; 

void Rectangle::set.values (int x, int y) { 
width = x; 
height = y; 

> 

void Rectangle::sleep () { 
cout << "\n"; 
for (int i=0; i<10;i++) { 
cout << i << "\n"; 

for (int k=0; k<1000000000;k++) { 
int temp=2+2; 

> 

> 

> 

int main () { 

Rectangle rect; 

rect.set_values (3,4); 

cout << "area: u " << rect.areaO; 

rect.sleep () ; 

return 0; 

> 


Abbildung 2: Listing C++ 


Nur, an ein gut programmiertes Forth kommt der C++ Sourcecode 
nicht heran. Ursache dafur ist, dass der Code vorher noch durch den 
Gnu C++ Compiler ubersetzt wird, was bedeutet dass man die Hil- 
fe weiterer Werkzeuge in Anspruch nimmt und sich ohne Not ab- 
hangig macht nicht nur von der x86 Architektur sondern auch von 
ineffizienten Compilern. Dadurch geht der Purismus den Forth Lieb- 
haber pflegen verloren. Dem Code fehlt jede Ausdruckskraft, es ist 
nicht empfehlenswert darin langere Programme zu schreiben. 

Schaut man sich einige C++ Beispiel-Spiele an die auf github 
gehostet sind so stellt man test, dass die Programmierer keinen ein- 
heitlichen Programmierstil verwenden, sondern haufig eine Mischung 
aus C und C++ schreiben. Fast schon zur Gewohnheit geworden 
ist es, auf das einleitende class statement zu verzichten und die C- 
Routinen einfach untereinander zu schreiben. Das mogen die Coder 
cool finden erschwert jedoch das Reverse Engineering wenn man mit 
cpp2dia und anderen Tools aus dem Code wieder ein UML Diagramm 
erzeugen will. Desweiteren hat sich bei C++ Programmierern die Un- 
sitte einburgert, Pointer auf sehr flexible Weise zu verwenden, offen- 
bar gibt es auch keinen Standard, sondern jeder baut sich das so wie 
er es mochte. Das einzige Kriterium scheint ein bugfreies Programm 
zu sein, also dass sich der Code in Maschinencode ubersetzen lasst. 
Nun mag man daruber hinwegsehen und diese Freiheiten den Pro¬ 
grammierern zugestehen, wenn zumindest die abgelieferten Spiele 
von hoher Gute waren, doch das sind sie ublicherweise nicht. C++ 
Spiele sind grundsatzlich langweilig. Immer geht es um irgendwelche 
Raumschiffe die durch Asteroiden Gurtel fliegen und der Spieler muss 
auf alles ballern was sich bewegt. Waren wir noch Anfang der 1980’er 
konnte man die Grafik loben, dass jemand uberhaupt ein Computer- 
spiel programmiert hat und das butteweiche Scrolling. Doch im Jahhr 
2017 interessiert sich dafur niemand mehr. Die Dinge auf die C++ Pro- 
grammier besonders acht geben ist bedeutungslos geworden. Worauf 
es heute ankommt sind eher wissenschaftlich ausgerichtete Projekte, 
wo also der Sourcecode ein vorhandenes Paper praktisch realisiert 
und was dazu dient damit andere die Ideen weiterentwickeln konnen. 
Das ist jedoch bei C++ und dessen Community nicht der Fall. 


2.4 Forth vs. Brainfuck 

Der Vergleich Forth vs C++ fiel noch ganz eindeutig fur Forth aus, C++ 
kann einfach mit dieser minmalistischen Programmiersprache nicht 
mithalten, was Eleganz, Lesbarkeit des Code und Komfort angeht. 
Wenn man jedoch einen Vergleich Forth vs. Brainfuck ansetzt sieht es 
schon nichtmehr so eindeutig aus. Brainfuck ist ahnlich wie Forth eine 
minimalistische Programmiersprache, es gibt sogar FPGA Implemen- 
tierungen die das ganze als IP Core realisieren. Das heiBt, Brainfuck 
ist dann Instruction Set und Programmiersprache in einem. Auf den 
ersten Blick besitzt Brainfuck gegenuber Forth den Nachteil dass es 
keine Worter anlegen kann. Aber, wenn man einen “macro preproces¬ 
sor" verwendet kann man sich Schlusselwdrter wie if, dup, und add 
definieren und damit dann richtig programimeren. Das heiBt, man gibt 
dup ein, und der Makroprozessor erzeugt daraus dann den Brainfuck 
Code. 

Brainfuck wird machmal mit APL verglichen. Es ist ebenfalls eine 
Minimal-Programmiersprache, und manche gehen soweit es als Es- 
oterische Sprache zu bezeichnen. Forth hingegen gilt nicht ais Es- 
oterische Joke Sprache und verfolgt anders als Brainfuck hohere 
Ziele. Will also ernstgenommen werden. Insofern muss man sagen, 
dass auch erneut Forth der klare Gewinner ist. Forth ist eine richtige 
Sprache, wahrend Brainfuck nur lustig ist. 

2.5 ABI-CODE 

Unter ABI wird das “Application binary interface" verstanden. Ein Stan¬ 
dard, uber den man Assembler Befehle unterschiedlicher Prozessoren 
vereinheitlicht. ABI-CODE bedeutet, dass man die x86 und AMD64 
linstruction Sets an die Forth Sprache bindet. Vergleichbar mit dem 
SWIG Interface bei Java. Der Sinn ist es, nicht einfach einen weiteren 
Compiler zu schreiben, der Sprache A nach Sprache B transformiert, 
sondern es geht zunachst einmal zu definieren, dass Opcode #1 auf 
einer 32 bit CPU das selbe bedeutet wie Opcode #33 auf einer an¬ 
deren 16 Bit CPU. 

ABI-CODE und die darauf aufbauende Idee eines portablen As¬ 
semblers, gemeint ist nicht C sondern eher Dinge wie C- und PAF, 
dass also ABI-CODE verwendet wird als Backend fur eine virtuelle 
Maschine. Der Ablauf konnte so aussehen: 

Python Sourcecode -> Python Bytecode -> ABI-CODE -> Forth- 
CPU 

Man hat daruber die komplette Pipeline abgebildet von einer objek- 
torientierten Hochsprache in der man extrem effizient programmieren 
kann bis hin zu einer Lowlevel CPU die im Beispiel einer GA144 CPU 
nur eine Stackmaschine darstellt, also als extrem minimalistisch gilt. 

2.6 Nachteile von Forth 

Es ist relativ schwer, Nachteile von Forth zu entdecken aber es 
gibt sie. Der Flaschenhals von Forth sind seine Programmierer. Ir- 
gendjemand muss den Sourcecode editieren und debuggen. Dabei 
kommt es zu den gleichen Herausforderungen wie bei alien anderen 
Programmiersprachen auch. Das heiBt in der Praxis dass auch der 
durchschnittliche Forthprogrammierer nur 10 Lines of Code pro Tag 
erstelien kann. Da bei Forth die Worter um Platz zu spuren und 
besonders effizienten Code zu suggerieren haufig nebeneinanderweg 
geschrieben werden und nicht untereinander, durfte die netto Zahl an 
Codezeilen sogar noch kleiner sein. Das diese Schatzung auf vali- 
den Daten beruht kann man bei einigen groBeren Forth Projekten se- 
hen. Die NASA hat Statistiken veroffentlicht wonach bei einem ihrer 
Forth Projekte pro Stunde 2 Zeilen Code in Forth entstanden sind 
(pro Kopf), und manchmal finden sich in den Implementierungen zu 
Virtual Maschines auch Angaben uber den Umfang des Projektes. 
Durchschnittliche Forth Projekte bringen es auf 500 bis 10000 Lines of 
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Code [2],Die Schwierigkeit besteht darin, dass Forth wie jede andere 
Sprache auch manuell programmiert wird und das der Schwierigkeits- 
grad zusatzlich noch erhoht ist. 

Der Begriff “Code Library” wird bei Forth mit einer anderen Be- 
deutung verwendet. Normalerweise stellt man sich darunter groBere 
Coderepositorien mit hundert Megabyte an Sourcecode vor. In der Ar- 
rayforth Implementierung heiBt Code Library, dass Befehle wie Swap, 
Jump und Dup bereits implementiert sind. Das heiBt, die Codeli¬ 
brary besteht aus weniger als 1000 Bytes. Auch das Forth Reposi¬ 
tory Forth.net 5 ist im Umfang deutlich reduziert. Es handelt sich urn 
nicht mehr als 100 kb in einer gepackten zip Datei wo Basis Funktio- 
nen aus der Mathematik und kleinere Forth Extension enthalten sind. 
Man sollte nicht den Fehler machen zu glauben, dass man in Forth 
programmieren konnen wie in C# und das es Bibliotheken gibt urn die 
Programmierung weiter zu erleichtern, sondern Forth ist eine lowlevel 
Sprache, sie wurde entwickelt urn auf Sub-Assembler Ebene mit der 
Flardware zu interagieren. 

2.7 Hochsprachen nach Forth konvertieren 

Wer wissen mochte wie man C Sourcecode nach Forth konvertiert ist 
damit nicht allein. in der offiziellen Fort FAQ taucht diese Frage ganz 
weit oben auf, so oft wird sie gestellt. Leider ist die Antwort ernuchtet- 
nd. Es geht nicht. Es gab zwar einige Versuche, aber das Ergebnis 
ist nicht besonders gut. Auch der Versuch, Java Bytecode nach Forth 
zu ubersetzen scheitert an Inkompiblitaten. Der Grund dafur ist, dass 
Forth ein minimalistsches System ist wahrend die ubrige Informatik 
einem Big is beautifull Schema huldigt. 

Doch gehen wir das Thema from scratch an. Eine virtuelle Mas- 
chine lasst sich halbwegs einfach in C programmieren. Also eine Com- 
putersimulation einer Registermachine an die man Befehle sendet 
wie “LDA #1” und die dann ausgefuhrt werden. Solche Virtuellen 
Maschinen kann man auch als Stackmaschine aufbauen, wozu es 
zwar wenig Literatur gibt, aber es ist grundsatzlich moglich. Der nach- 
ste Schritt besteht dann darin, einen Hochsprachencompiler fur diese 
Virtuelle Maschine zu schreiben, also einen Konverter der normalen 
C Sourcecode auf diese Maschine ubersetzt. Oblicherweise geht dies 
mit Bison/yacc. Man parst zuerst den Sourcecode, erstellt daraus 
einen Abstract Syntax Tree und wandelt diesen dann in assembler- 
befehie urn, die werden zum Schluss noch in Maschinenopcodes ver- 
wandelt welche man dann auf der virtuellen Maschine ausfuhrt. 

Die Lehrbucher der Informatik erlautern Oblicherweise das Pro¬ 
grammieren eines Compilers fur Registermachinen aber rein theo- 
retisch ist auch ein Compiler fur eine Stackmaschine vorstellbar. Nur 
das Problem ist, dass der damit erzeugte Code niemals optimal ist. In 
der klasschen Informatik akzeptiert man dies, obwohl bekannt ist dass 
beim Umwandeln von C nach Maschinencode Performance verloren 
geht, nimmt man das in Kauf, weil man in einer Plochsprache leichter 
programmieren kann. 

Versuchen wir das jetzt auf die Forth Welt zu ubertragen. Aus Sicht 
der Forth Puristen kommen Compiler nach Forth nicht in Frage. Sie 
wurden immer nur suboptimalen Code erzeugen, also Code der durch 
Software generiert wurde, nicht jedoch manuell geschrieben wurde. 
Und irgendwie macht es auch keinen Sinn wenn man zuerst eine Min- 
imalistische Programmiersprache entwirft, nur urn darauf dann subop¬ 
timalen Code auszufuhren. Die einzig richtige Antwort darauf lautet, 
dass man Forth am besten manuell zu FuB schreibt. 

Man kann sich eine Forth CPU also wie einen Koprozessor 
vorstellen. Er ist nicht dazu gedacht eine Standard-CPU zu ersetzen 
sondern wird verwendet urn rechenintensive Aufgaben auszulagern. 
Will man fur eine Forth CPU ein Programm schreiben, muss man es 
erst in einer Plochsprache Prototypen. Am besten eignet sich Python 
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dazu. Und wenn die Software fehlerfrei lauft ubertragt man einen Teil 
des Codes nach Forth. 

Obwohl sich das zunachst wie unnotiger Mehraufwand anhort ist 
so aufwendig der Vorgang nicht. Wenn der Algorithmus erstmal spez- 
ifiziert wurde, ist es relativ einfach diesen in Forth nachzuprogram- 
mieren. Man weiB ja bereits, welche Subfunktionen benotigt wer¬ 
den. Das heiBt, man kann in Forth selber die Losung eines Prob¬ 
lems nicht finden. Dazu fehlt es bei Forth an zahlreichen Bequem- 
lichkeiten wie objektorientierter Programmierung, Grafikausgabe und 
leichter Syntax. Man kann jedoch Forth als Zweitsprache nutzen, urn 
ein Primzahlsieb in tausendfacher Beschleunigung zu berechnen. 

Vermutlich wurde mit diesem Plintergedanken auch die GA144 en¬ 
twickelt. Nicht als Desktop-Ersatz urn damit im Internet zu surfen, son¬ 
dern als Pligh-Performance-Computer wenn man viel Rechenleistung 
benotigt. Forth Programmierung hat groBe Ahnlichkeit als wenn man 
eine Grafikkarte programmiert. Es wird das bereits erstellte Programm 
lediglich auf die Flardware angepasst. 

Finite State Machine Forth darf man nicht mit einem Desktop PC 
verwecheln, wo man ein Betriebssystem hat und objektorientiert en¬ 
twickelt. Sondern man muss sich auf Forth einlassen, das heiBt es 
so verwenden wie es gedacht ist. Damit ist gemeint, dass man for- 
male Methoden insbesondere Finite-State-Machines anwendet. Auf 
seinem Desktop PC wo windows, Linux oder was auch immer drauf 
ist, kann man schicke GUIs zusammenklicken, Oder sich Algorith- 
men ausdenken, aber wenn man diese dann auf konkreter Flard¬ 
ware implementieren will kommt Forth ins Spiel. Flat man seinen Al¬ 
gorithmus so klar spezifziziert, dass sein State-Diagramm auf eine 
DIN A4 Seite draufgeht, dann ist der Zeitpunkt gekommen fur eine 
Portierung nach Forth. Das heiBt, es gibt fur Forth keine Codegen- 
eratoren und auch keine Converter aus anderen Sprachen, sondern 
die Best-Practice Methode ist nochmal bei Null anzufangen. Also ein 
komplett neues Forth Programm zu schreiben, die benotigten Subrou- 
tinen zu definieren und genau den Algorithmus implementieren den 
man vorher im Simulator getestet hat. 

Und hier wird deutlich, was mdgliche schlechtere Alternativen zu 
Forth waren. Eine Methode besteht darin, den Microcontroller in As¬ 
sembler zu programmieren. Das hat jedoch den Nachteil, dass man 
es fur jeden Microcontroller einzeln machen muss, weil sich die Op¬ 
codes andern. Eine zweite Alternative ist die Verwendung eines C- 
Compilers. Aber ein C-Compiler erzeugt jedesmal ebenfalls anderen 
Code und man hat dort nicht die voile Kontrolle uber das Ergeb¬ 
nis. Forth hingegen macht nur das, was man explizit programmiert 
hat. Das ist ideal geeignet wenn man das Bios modifiziert oder kryp- 
tographische Algorithmen implementieren mochte. 

Kommen wir an dieser Stelle zu einem anderen Thema: Forth 
& Robotik. In vielen Papern ist zu lesen, dass mit Forth Robot- 
er programmiert wurden. Man darf diese Behauptung nicht wortlich 
nehmen. Ja ich wurde sogar behaupten, dass es ausgechlossen ist, 
dass jemand nur mit Forth einen Roboterprototypen entwickelt hat 
oder einen biped Controller darin programmiert hat. Sondern der 
Ablauf in der Praxis durfte eher so sein, dass man 10 Jahre lang mit 
Windows einen Roboter-Controller in der Simulation optimiert hat und 
dann als Sahnehaupchen die Finte-State-Machine in sauberem Forth 
nachprogrammert hat und die dann auf dem Microcontroller ausfuhrt. 
Also bereits getesteten Code, der die nachsten 20 Jahre unverandert 
bleibt. Forth als ROM Chip sozusagen. 

Ein gutes Beispiel durfte die Speech-Synthese in Turboforth sein. 
Turboforth ist ein Dialekt, der test in einem Taschenrechner als ROM 
eingebaut ist. Die Sprachsynthese ist nicht veranderbar, man kann 
sie lediglich aufrufen. Sie wurde mit Sicherheit nicht unter Forth pro¬ 
grammiert, sondern wurde vermutlich in einem Tonstudio generiert, 
auf einem Desktop PC und dann lediglich in Turboforth bereitgestellt. 
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Finite State Machine Mit den obigen Ausfuhrungen lasst sich 
sagen, wie genau in Forth programmiert wird. Man muss den Algo- 
rithmus den man implementieren mochte, schon ais Finite State Ma¬ 
chine vorliegen haben. Also in einer extrem reduzierten Form, wo 
man sehr genau wei(3 wie die Losung aussieht. Diese Losung kann 
man dann fast 1:1 in Forth programmieren. Anstatt der States definiert 
man Words, und probiert dann ein wenig mit dem Stack herum. Am 
Ende sollte der Algorithmus so laufen wie geplant. Wenn Probleme 
auftreten, dann lediglich in Detailfragen, also wie Forth einen Float 
nach Integer konvertiert Oder ahnliches. 

Kommen wir jetzt zum Anti-Forth Pattern. Man hat noch gar kein 
State-Diagramm, und es liegt auch kein Pseudocode in der Sprache 
Python vor. Jetzt ist Forth leider die falsche Sprache. Sondern hier 
muss man erstmal sich recherchieren, also sich uberlegen wie der Al¬ 
gorithmus aussieht und einige Prototypen in Python schreiben. Also 
klassische Informatik ohne Forth durchfuhren. Die Forth Sprache mit 
seinen lowlevel Fahigkeiten hilft nicht im geringsten dabei Algorith- 
men zu erfinden Oder groBerere Prototypen zu testen. Forth ist eher 
der letzte Schritt in einem Software-Engineering Projekt. Wo man al¬ 
so uber Jahre hinweg die mathematische Literatur ausgewertet hat, 
und Programme geschrieben hat und jetzt die fertige Losung ais Forth 
Sourcecode einprogrammiert. 

2.8 Wie gut ist das Software-Engineering bei Forth 
Projekten? 

Auf Hardwareebene kann man getrost behaupten, dass die Forth 
Community Ahnung hat. Nicht nur, dass die Forth Chips sehr effizient 
sind, sondern auch Forth ais maschinennahe Bytecode Sprache ist 
unubertroffen. Eigentlich musste man die Java Virtual Engine mit 
Forth Code bestucken, sie ware dann urn einiges leistungsfahiger. 

So sehr man auch die Leistungen von Forth im Bereich machinen- 
nahe Programmierung wurdigen muss so wenig vermag Forth eine 
Antwort auf die Themen Robotik und Kunstliche intelligenz geben. Es 
ist zwar richtig, dass in den 1980’er Jahren einige Robotik-Projekte 
mit Forth realisiert wurden, aber diese unterscheiden sich nicht stark 
ais wenn man C einsetzt. Bei Kunstlicher Intelligenz geht es selten 
urn die Performance der Plardware sondern ganz uberwiegend stehen 
Software-Engineering Fragen im Mittelpunkt. Und hier macht Forth 
leider keine ruhmliche Figur. Die Sprache selber unterstutzt kein ob- 
jektorientiertes Programmmieren, was es erschwert komplexere An- 
wendungen zu schreiben. Und minimalistische Robotersoftware zu 
schreiben ist fur die Programmierer zu komplex. Eln Roboter ist etwas 
anderes ais ein Microchip. Urn einen Roboter zu programmieren muss 
man viel Domanenwissen in Computercode unterbringen. Schaut 
man sich real durchgefuhrten Forth Projekte aus dieser Richtung ein- 
mal an, so waren sie nicht besonders erfolgreich darin. 

In der Theorie her kann man mit Sicherheit ein Roboter- 
Steuerungsprogramm in 50 Kilobyte an Forth Sourcecode unterbrin¬ 
gen. Mehr braucht es vermutlich nicht urn eine inverse Kinematik, Mo¬ 
tion Primitive und ein wenig Bildverarbeitung zu betreiben. Das Prob¬ 
lem liegt eher auf der Programmiererseite. Ein solches Programm 
schreibt sich nicht von allein, jemand muss sich die Behavior Trees 
ausdenken, die Sache debuggen usw. Das geht mit Forth leider nicht 
so gut. Wenn man schon eine umfangreiche Robotersoftware in Java 
geschrieben hat kann man diese garantiert auf Forth portieren. Dabei 
wurde man die wichtigssten Algorithmus auf ihre Kernbestandteile re- 
duzieren und die vielen Hilfsroutinen die bei der Entwicklung benotigt 
wurden einfach weglassen. Nur, dazu muss man den umfangreichen 
Java Code erstmal haben. Und genau hier liegt das Problem. Derzeit 
ist auBerhalb von Forth nur wenig positives zu berichten. 

Ich will mal versuchen ausfuhrlicher zu erlautern, warum Forth 
bei der Robotik Programmierung keine Hilfe darstellt. Ublicherweise 


wird ein Robot-Control-System bottom up programmiert. Es treten 
dort viele kleine Probleme die nacheinander geiost werden mussen. 
Beispielsweise muss benotigt man die Formel mit der man ein Au¬ 
to auf einen Waypoint hinlenken kann. Die Formel dafur findet sich 
meist bei Stackoverflow oder man findet sie selber durch herumpro- 
bieren aus. Mit programmieren im eigentlichen Sinn hat das nichts zu 
tun, eher damit dass man in einer Tabellenkalkulation die Werte ein- 
tragt und damit herumspielt. Das eigentliche Programmieren besteht 
darin, dass man die Formel dann ais Sourcecode aufschreibt. Selb- 
stverstandlich kann man dies in Forth tun, aber jede andere Sprache 
wie Python und Co eignet sich dafur genauso gut. Die meiste geht al¬ 
so nicht dabei dabei drauf, dass man im Speicher mit Pointern hantiert 
oder Code schreibt, sondern damit dass man Stackoverflow durch- 
sucht, mit dem Roboter herumprobiert und solche Dinge. Dabei kann 
Forth leider null helfen. 

2.9 Parallelentwicklung in Python und Forth 

Wenn man Forth einsetzt ergibt sich die Frage woher man den 
Sourcecode bekommen mochte. StandardmaBig wird bei einer Forth 
Engine exakt null ausfuhrbarer Code mitgeliefert, auch keine Libraries 
oder gar Robot-Control-Systeme. Die Antwort lautet, dass man paral¬ 
lel zu Forth noch in einer anderen Sprache programmiert. Die best- 
practice Methode sieht so aus, dass man zuerst in Python einen 2D 
Simulator fur ein Micromouse Labyrinth schreibt, darin dann ebenfalls 
in Python einen Behavior Tree fur einen autonomen Agenten entwicklt 
und die die Software lauft extrahiert man daraus stripdown die wichtig- 
sten Codeteile und portiert sie nach Forth. Fur den Simulator mitsamt 
Kl wird man 2000 Zeilen Code in Python benotigen vermutlich eher 
mehr, wenn der Roboter in den Kurven ein ausdriften vermeiden soil. 
Und daraus kann man dann die wenigen wichtigen Stellen heraus- 
nehmen. Vielleicht 20 Funktionen und die sehr kompakt in Forth Code 
schreiben. So dass man am Ende eine Minidatei mit 2 kb hat die man 
auf den echten Micromouse Roboter draufflasht. 

Der Vorteil ist, dass der Microcontroller ruhig “c-compiler unfriend¬ 
ly” sein darf, weil Forth bekanntlich uberall lauft. Wenn es Bug auftritt 
fixt man den zuerst im Python Simulator und passt anschlieBend 
den Forth Code an. Was zunachst einmal wie eine muhsame Dop- 
pelentwicklung klingt ist erstaunlich effizient. Wenn man bereits aus- 
fuhrbaren Python Code besitzt fur das Steering und die Pfadplannung 
lasst sich dieser relativ unkompilizert in Forth nochmal neuschreiben. 
Theoretisch kann man den Python Code auch nochmal in Assembly 
neu formulieren, nur Assembler andert sich bei jedem Microcontroller. 
Man ware dann auf eine Plattform festgelegt. Und ebenfalls rein theo¬ 
retisch kann man den Python Code auch nach C ubertragen und von 
dort nach Assembler ubersetzen. Nur, ob man den Code nach C oder 
nach Forth konvertiert macht keinen groBen Unterschied. Und Forth 
hat den Vorteil dass klarerer wird urn was es geht: eine minimale Pro- 
grammdatei mit ausfuhrbarem Code. 

Was jedoch nicht funktioniert ist wenn man auf den Prototypen 
in Python verzichtet, also gar keine 2D Simualtion nutzt und gle- 
ich bare metal die Pfadplannungsalgorithmen in Forth formuliert. Der 
Schwierigkeitsgrad ist zu hoch, das muss scheitern. Wobei das nicht 
nur bei Forth scheitert, sondern nicht viel anders in C geht. Wer ver- 
sucht direkt einen Roboter in C zu programmieren ohne vorher im 2D 
Simulator verschiedene Algorithmen ausprobiert zu haben wird eben¬ 
falls sehen, dass es nicht geht. Es ist eben keine Kleinigkeit eine Mi¬ 
cromouse durchs Labyrinth zu schicken. 

C vs Forth Forth hat gegenuber C aber auch Nachteile. Wenn der 
Algorithmus sehr kompliziert ist und Arrays verwendet ist es leichter 
ihn in C zu programmieren und nach Machine Code zu compilieren. 
Desweiteren gilt normales C bereits ais Anspruchsvoll in der Bedi- 
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enung und Forth ist vom Schwierigkeitsgrad noch hoher. Wer einfach 
nur einen funktionierenden Roboter haben will ist kann sogar auf C 
und Forth komplett verzichten und stattdessen einen Microcontroller 
nutzen auf dem Python lauft. Er wird dann noch schneller den Algo- 
rithmus darauf portieren. 

2.10 Definition einer Toylanguage 

Der Begriff Toylanguage wird manchmal verwendet um auszudrucken 
dass man eine Sprache nicht mag. So behaupten C++ Hater, dass es 
sich dabei um eine Toylanguage handeln wurde. Doch man kann auch 
objektive Kriterien anfuhren und zwar das Vorhandensein von Soft- 
warebibliotheken. Unzweifelhaft besitzt C++ eine sehr gro(3e Anzahl 
von Librarys ist also per Definition keine Toylanguage. Das ich person- 
lich C++ nicht mag ist dabei egal. Fakt ist jedenfalls dass die Sprache 
intensiv eingesetzt wird und dass in den Librarys wiederkehrende 
Probleme gelost wurden. 

Als Toylanguage par excellence kann man hingegen Brainfuck 
bezeichnen. Dort gibt es nur sehr wenige Libraries. Das heiBt, Brain¬ 
fuck wird nicht verwendet um darin effektiv Programme zu schreiben 
sondern Brainfuck steht selbst im Fokus. Es ist also eine akademis- 
che Sprache. Und hier ist der Ubergang zu Forth gegeben, auch zu 
Forth gibt es keine Libraries, jedenfalls keine umfangreichen. Mit et- 
was suchen stoBt man auf “The forth net" welche aber nur doku- 
mentarischen Charakter besitzt und allein vom Umfang her sehr klein 
ist. Demnach ist auch Forth eine Toylanguage. Naturlich kann man 
Forth in eine professionelle Sprache verwandeln und dafur Libraries 
schreiben, doch derzeit ist das nicht der Fall. Offenbar gibt es also 
zuwenig Leute die das versuchen. 

Auch die anderen Programmiersprachen kann man anhand der 
Fulle vorhandener Bibliotheken in Toylanguage Oder echte Sprache 
untergliedern. Die bekannten groBen Sprachen wie Java, C#, C und 
Python sind uber jeden Zweifel erhaben. Sie besitzen mehr als 1000 
Librarys, teilweise sogar mehr als 100000. Das ist Ausdruck von 
sozialen Einschatzungen. Das heiBt, wie gut eine Sprache von den 
Programmierern angenommen wird und wieviel Energie in den Auf- 
bau von Bibliotheken gesteckt wird. Will man nichts verkehrt machen 
sucht man sich einfach jene Sprache welche die meisten Bibliotheken 
besitzt und hat damit eine Sprache ausgewahlt, die im Produktivein- 
satz verwendet wird und nicht nur von akademischem Interesse ist. 

Wie man an diesem kleinen Exkurs gesehen hat, erfullen Pro¬ 
grammiersprachen uberwiegend einen sozialen Zweck. Sie werden 
von Menschen verwendet, weil sie ein Problem losen wollen oder 
programmieren lernen mochten. Eine Programmiersprache ist nur so 
gut, wie die Community dazu. Doch kommen wir zu Forth. Forth ist 
eine Sprache ohne Library. Ahnlich wie Brainfuck ist die Sprache in- 
tellektuell interessant aber es fehlt an einer Community die sie frei- 
willig spricht. Die Anzahl der Paper die sich mit Forth beschaftigen 
ist weitaus hoher als die tatsachlich durchgefuhrten Projekte in Forth. 
Woran das liegt ist simpel: Forth wurde auf eine leichter Interpretier- 
barkeit durch Interpreter entwickelt. Forth ist ahnlich leicht zu parsen 
wie Brainfuck. Sie orientiert sich an Maschinen nicht aber an Men¬ 
schen. 

3 Virtualisierung 

3.1 Forth ist eine Virtuelle Maschine 

Damit Forth Befehle auf einer Standard-CPU ausgefuhrt werden kon- 
nen benotigt man eine virtuelle Maschine. Also ein Computerpro- 
gramm was Forth Code in Maschinenopcodes des Prozessor uberset- 
zt. Eine solche Virtuelle Maschine wird als Forth System bezeichnet. 
Ublicherweise sind diese Maschinen in Assembler programmiert und 


auf die jeweilige CPU angepasst. In dem NEXT Befehl ist der Kern 
dieser VM verborgen. NEXT bedeutet, dass der aktuelle Forth Befehl 
auf der Hardware ausgefuhrt wird. Will man auf eine Virtuelle Mas¬ 
chine muss man Forth direkt in Hardware ausfuhren, dazu benotigt 
man einen dezidierten Forth Prozessor. 

Wie man vielleicht schon ahnt gibt es dieses Konzept nicht nur 
bei Forth. Auch pyCPU (Python Hardware Processsor). Wiedereinmal 
mehr ist Forth seiner Zeit also weit voraus. 

3.2 Forth is dead? Ja 

Vor einiger Zeit fragte Paul Frenger in einem Text der in einer ACM 
Fachzeitschrift erschien ob Forth nicht langst uberholt sei [6]. Die 
Antwort auf diese ernstgemeinte Frage lautet, dass Forth in der Tat 
obsolet ist, es gibt langst bessere Scripting Sprachen welche Forth 
ersetzen konnen. Eine davon ist Javascript. Fur Javascript gibt es in- 
zwischen ausgezeichnete x86 Emulatoren 6 womit man die x86 CPU in 
einem Browserfenster simulieren kann und darin dann MS-DOS, Win¬ 
dows 1.0 oder was auch immer startet. Die Geschwindigkeit solch- 
er Emulatoren, die es ubrigens auch fur die MOS6502 CPU sind ist 
ausgesprochen gut. Man kann also sagen, dass sich mit geschickter 
Programmierung zu Forth eine Alternative bietet. 

3.3 CPU Simulator in Forth? 

ich habe jetzt mehrfach versucht, Teile meiner eigenen Robotics- 
Library nach Forth zu portieren. Eigentlich eine simple Aufgabe, weil 
der Code vorher von mir selbst in Python geschrieben wurde und es 
leicht sein musste ihn in die Python Syntax zu uberfuhren. Aber es hat 
nicht funktioniert. Zwei kleine Funktionen zur Abstandsberechnung 
zwischen zwei Punkten habe ich hinbekommen. Der Zeitaufwand 
dafur war imens. Und wenn man komplexere Funktionen die Array Ma- 
nipulationen benotigen nach Forth ubertragen will, durfte es vermut- 
lich Jahre dauern bis der Code getestet ist. Es verwundert daher nicht, 
dass es fOr Forth fast keine Beispielprogramme gibt. Die Sprache ist 
unprogrammierbar. Dagegen ist Assembler ja noch als leicht zu beze¬ 
ichnen. 

Es stellt sich also die Frage was man mit Forth anfangen kann. 
Einfach ignorieren ware eine Methode. Spannend ware es, wenn es 
aber doch irgendwie gelingt dafur Programme zu schreiben. Eine 
Moglichkeit ware die CPU Emulation. Zur Erinnerung: heutige C- 
Compiler setzen einen Instruction Set voraus und zwar den AMD64 
Standard. Dieser zeichnet sich dadurch aus, dass es relativ viele Be¬ 
fehle gibt und mindestens 30 Register (besser mehr) verfugbar sind. 
Dafur optimiert der C-Compiler dann den Code. Ein Forth Chip stellt 
diesen Instruction Set nicht zur Verfugung, also kann man auch keine 
C-Compiler nutzen um dafur Progrmame zu compilieren. Es gibt jetzt 
zwei Optionen: entweder verbessert man die C-Compiler, so dass sie 
als Ausgabe Forth Code erzeugen, oder man schreibt in Forth einen 
x86 Simulator, so dass man in Forth AMD64 Code ausfuhren kann. 

Aber bevor man sich an einen CPU Simulator in Forth wagt kann 
man erstmal mit Python sein Gluck versuchen. Es gibt mehrere - halb- 
wegs leicht verstandliche - Projekte wie z.B. py65 was eine MOS 
6502 CPU in Python nachbildet. Von der Funktion vergleichbar mit 
qemu nur eben sehr viel kompakter. Nicht die Geschwindigkeit steht 
im Vordergrund sondern dass der Code schon leicht verstandlich in 
Python programmiert wurde. Und an diesen Python Code kann man 
dann 6502 Assembler Befehle senden, so jedenfalls die Idee dahinter. 

Theoretisch ware es mdglich, py65 nach Forth zu portieren und 
plotzlich konnte man dann in Forth einen C-64 booten. Dadurch ware 
dann massenhaft Software die fur den C-64 entwickelt wurde auch 

6 https://github.com/copy/v86 
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unter Forth lauffahig. Man konnte so ein Stuckweit die Forth Soft- 
warekrise entscharfen. Wenn ich mich recht entsinne habe ich irgend- 
wo schonmal eine halbfertige Implementierung in Forth gesehen die 
aus 100 Lines of Code bestand. Das heiGt, offenbar bin ich nicht der 
einzige der daruber nachgrubelt. 

GewissermaGen stellt Forth die letzte groGe Bastian da. Es ist ver- 
gleichbar mit einem schwer zu besteigenden Berg. Vielleicht gelingt 
es eines Tages, dorthin einen Weg zu schlagen. 

4 Rekursion 

4.1 Rekursive Kunstliche Intelligenz 

In der Kunstlichen Intelligenz gibt es eine Subdisziplin namens rekur¬ 
sive selbst-modifizierende Algorithmen zur Erlangung von Super- 
Fluman-AI, abekurzt AIXI. Vereinfacht gesegt soil sich einerseits die 
Funktion selbst immer wieder aufrufen, aber dabei noch den Source- 
code modifizieren. Wenn man jetzt sowas explizit als Aufgabe for- 
muliert, dann ist Forth die geeignete Programmiersprache dafur. Nicht 
nur dass Rekursive Aufrufe sehr gut unterstutzt werden, sondern auch 
das Verandern des eigenen Codes zu Laufzeit ist ein Wesensmerkmal 
von Forth. Ob man soetwas realisieren kann ist unklar, aber es passt 
zumindest technisch ziemlich gut zusammen. 

Unter dem Stichwort “Super-recursive Algorithm” wird anders als 
bei AIXI konkrete praktische Beispiele diskutiert. Also mathematische 
Verfahren wo selbst-lernende Turing-Maschinen angestrebt werden. 
Obwohl das nicht explizit unter dem Stichwort Forth Programming 
lauft, eignen sich Stackmaschinen jedoch ausgezeichnet dafur der- 
artige Algorithmen praktisch umzusetzen. 

Nochmal: Compiler fur Stackmachinen Ausgangspunkt war die 
Uberlegung, dass Registermaschinen als C-friendly gelten und Stack¬ 
machinen als C-unfriendly. Daraus ergibt sich das Problem wie man 
fur Stackmachinen wie die GA144 Software schreiben soil. Ein C- 
Compiler gibt es dafur nicht und vermutlich wird auch nie einer er- 
funden. Also besteht der Ausweg darin, sich Probleme zu suchen, 
die dezidiert fur Stackmaschinen geschaffen wurden. Und voila, man 
gelangt auf direktem Wege zu superrekursiven Problemen. Wo also 
die Studenten schon in der Aufgabenstellung dazu angehalten wer¬ 
den, Rekursion und einen Stack zu nutzen. Solche Probleme sind wie 
geschaffen fur die Sprache Forth und fur Forth CPUs. 

Kennt man den Algorithmus kann man ihn fast als Pseudocode in 
den Forth Interpreter eintippen. Das spart Zeit und einen C-Compiler 
vermisst man auch nicht. 

4.2 Grenzen der Rekursion 

Wer die Arbeiten von Jurgen Schmidthuber kennt wird sich garantiert 
gefragt haben, ob die vorgeschlagene Kunstliche Intelligenz realis- 
tisch ist und wie man sie in Forth implementiert. Genauer gesagt 
lautet die Frage ob man sehr kurzen aber umso raffenierteren Al- 
goirthmen Intelligenz erzeugen kann. Also ein Programm konstruieren 
was mittels Stack arbeitet, sich selber aufruft, womoglich eigene Forth 
Words erzeugt und dabei standig intelligenter wird und sich immer 
mehr dem Ziel anpasst. Die Antwort darauf lautet nein, die Suche 
danach ist vergleichbar als wenn Physiker versuchen ein Perpetum 
Mobile zu bauen. Beweisen lasst sich diese ernuchtene Feststellung 
nicht direkt, aber anhand von real durchgefuhrten Programmierpro- 
jekten spricht viel dafur. Schauen wir uns einmal typische Programme 
an, die nach dem Rekursions-Schema arbeiten und sich der Chaos- 
theorie verpflichtet pfuhlen. Die Gemeinsamkeit besteht darin, dass 
sie sehr kurz sind, im Sinne von wenig Zeilen Code. Und das unab- 
hangig davon ob sie in Java Oder Forth erstellt wurden. Auch der Area 


Filling Algorithmus den Elizabeth Rather in den 1980'er Jahren in ein¬ 
er Folge von Computer Chronicles vorgestellt hat war sehr kurz und 
mit sicherheit verwendete er Rekursion. Und was sich daruber sagen 
lasst ist, dass es nicht funktioniert. 

Der Grund warum die klassische Informatik Rekursion als Hexen- 
werk und Forth Chips als Holle bezeichnet ist nicht etwa weil sie uns 
davor warnen will weil es zu machtig ist, sondern weil Rekursion eine 
schwache Technik ist. Damit ist gemeint, dass Superhuman -Al mit 
Sicherheit nicht in ein 10 kb groGes Forth Programm hineinpasst was 
sich irgendwie im Speicher vermehrt, sondern echte Kunstliche In¬ 
telligenz basiert auf einer MaGzahl aus der klassischen Informatik, 
gemeint sind Lines of Code. Will man die Komplexitat also die Leis- 
tungsfahigkeit von Software erhohen so muss man diesen Wert nach 
oben justieren. Dadurch stellt sich fast von allein soetwas wie Eleganz, 
Performance und Leistung ein. 

Die Schwierigkeit mit Rekursiven Algorithmen und speziell super¬ 
rekursiven Algoirthmen ist, dass sie wie der Name schon andeuten an 
einem Berechenbarkeitsmodell orientiert sind. Die Losung also darin 
sehen, dass die CPU eine Aktion ausfuhrt und zu weiteren Sprun- 
gadressen im Speicher springt. Das ist jedoch nicht die Losung, son¬ 
dern das ist die Basis urn uberhaupt eine Losung in Erwagung zu 
ziehen. 

Werfen wir nochmal einen Blick auf den C-Compiler welcher von 
der Forth Community manchmal belachelt wird. Die Sprache C be- 
sagt, dass die Hardware im Grunde egal ist. Es spielt keine Rolle 
ob man die Software fur eine Stackmachine, eine virtuelle Maschine 
Oder einen Supercomputer programmiert, das einzige was zahlt ist der 
Sourcecode. Wie der ausgefuhrt wird ist Sache von anderen. Diese 
Uberheblichkeit gegenuber Lowlevel CPU Architekturen ist symp- 
tomatisch fur die Mainstream-lnformatik und sie ist das staarkere Ar¬ 
gument. Damit ist gemeint, dass rekusrive Algorithmen, Stacks und 
Forth keine eingebaute Intelligenz besitzen, die man nur freischalten 
musste, sondern das Software genau das ist, was man einprogram- 
miert hat. Und je mehr Codezeilen ein Programm hat, desto mehr 
Intelligenz ist darin enthalten. 

Bei Mini-Programmen im Umfang von 10 kb welche Super- 
Intelligenz versprechen hat man immer den Eindruck, als ob eine 
sehr naive Vorstellung vorhanden ist. Nach dem Motto, dass die 
Turing-Maschine bereits intelligent sei, und man lediglich den Schlus- 
sel in Form des Sourcecode brauchte urn diese Grundintelligenz 
zu aktivieren. So ahnlich als wurde man Energie aus dem Vakuum 
schopfen, wenn man weiG wie es geht. Das ist das genaue Gegenteil 
von Wissenschaft, das ist magisches Denken. Genau diesem Virus 
sind Jurgen Schmidhuber und andere aufgesessen und sie glauben, 
dass Rekursion und Stacks der Schlussel sind. 

Quellen Vielleicht fragt mich der eine Oder andere, wo denn meine 
Quellen fur diese kuhnen Thesen seien und wie ich das beweisen 
mochte. Meine Quellen sind nichts geringeres als die tatsachlich 
durchgefuhrten Roboterwettbewerbe. Wo also Aufgaben gestellt wer¬ 
den, die von Teams unter kontrollierten Bedingungen abgearbeitet 
werden mussen. Da jedes Team gewinnen will ist anzunehmen, dass 
solche Wettbewerbe ein Sammelbecken fur effiziente Algorithmen 
sind. Das interessante ist, dass sich im laufe der Jahre jene Software 
durchgesetzt hat, die aus mehr Zeilen Code bestand und gleichzeitig 
dass noch nie rekursive stack-basierende Verfahren zur Anwendung 
kamen. Probiert wurde es, nur brachte es keinen Erfolg, Also hat man 
wieder Abstand genommen. Wer also glaubt, doch mit rekursiven Ver¬ 
fahren und Programmen die in Forth geschrieben wurden, bei solchen 
Wettbewerben gewinnen zu konnen, nur Mut, deine Mitarbeit ist er- 
wunscht. Allerdings befindet man sich damit in der Defensive, in dem 
Sinne dass man das beweisen muss was sehr unwahrscheinlich ist. 

Woran das genau liegt, dass man die Intelligenz eines Roboters 
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verdoppelt wenn man die Lines of Code des Projektes verdoppelt 
hingegen nicht der gleiche Erfolg eintritt wenn man sich bessere, 
rekursive Algorithmen uberlegt ist nicht so ganz geklart. Ich argu- 
mentiere hier auch nicht von einer theoretischen Perspektive sondern 
beshreibe die Wirklichkeit bottom up. Es ist eine Beobachtung. Man 
konnte es ungefahr so deuten, dass eine Maschine also ein Computer 
nach dem Einschalten Null Intelligenz besitzt und das jede Funktional- 
itat die man benotigt muhsam einprogrammiert werden muss und das 
der Aufwand dafur steigt, je mehr Zeilen Code man erstellt. 

Medium Computer Die C-Programmierer und die Forth Program- 
mierer konnten unterschiedlich nicht sein. Wer in C programmiert hat 
akzeptiert dass der Computer nur ein Medium ist, ahnlich wie die Lein- 
wand in einem Kino muss man sie bespielen und zwar mit selbst aus- 
gedachter Software. Forth Programmierer hingegen hangen an der 
Idee, dass der Computer selbst das Medium ware. Folglich sehen sie 
nicht Sourcecode als das wichtigste sondern sie fokussieren auf die 
Plardware des Rechners. Forth Programmierer glauben, der Film ware 
schon da, man musste nur genau hinschauen. Manchmal setzen sie 
auch spezielle Programme ein, die sich Artificial General Intelligenz 
nennen und was die Aufgabe hat, den imaginaren Film freizuschal- 
ten. 

Man kann sagen, dass Forth Programmierer sich einen naiven Zu- 
gang zum Computer bewahrt haben. Sie denken nicht, dass selbst 
programmierte Software der Schlussel ist, sondern dass minimal Pro¬ 
gramme und gut implementierte Algorithmen besser geeignet sind fur 
einen Zugang zur Maschine. 

4.3 Codegenerator 

In der traditionellen Informatik dient ein C-Compiler als Codegen¬ 
erator. Der User gibt dort Pseudocode ein und erzeugt dann den 
passenden Maschiinencode. Da bei Forth kein C-Compiler funktion- 
iert stellt sich die Frage nach moglichen alternativen Codegenera- 
toren. Die einfachte Moglichkeit ist, wenn man den Code einfach sel- 
ber erstellt. Das heiBt, zuerst erstellt man in den Code, testet ihn und 
wenn er funktioniert portiert man ihn in die Forth Syntax. Ein wenig 
besser ist es, wenn man das Forth so anpasst, dass es C-friendly wird, 
also Register emuiiert, damit man leichter fur diese Plattform Code 
erzeugen kann. Als dritte Moglichkeit kann man auch eine sehr forth- 
typische Losungsstrategie verwenden. Diese besteht darin, die Auf- 
gabenstellung komplett zu ignorieren und stattdessen die passende 
Aufgabe fur den Plammer zu suchen den man besitzt. Eine passende 
Aufgabe wie gemacht fur Forth hat etwas mit dem Stack zu tun und 
ist rekursiv formuliert. Und voila, dass ist aus Sicht von Forth die be- 
friedigenste Antwort. 

Man sucht sich also einen Programmierwettbewerb, bei dem die 
Teilnehmer ein Fraktal erzeugen lassen und dazu einen Stack ver¬ 
wenden sollen. Sowas lasst sich sehr gut in Forth implementieren. 
Man kann da schon ein Word definieren, was sich selber aufruft, und 
Variablen braucht man auch keine. 

Passende Probleme fur das vorhandene Werkzeug Die Aus- 
fuhrungen der Einleitung mochte ich etwas vertiefen. Als Codegenera¬ 
tor bezeichnet sich das VFX Forth Environment. Es handelt sich dabei 
urn ein kommerzielles Paket mit dem man Forth Programme erstellen 
kann. Das lauft unter MS-Windows und es werden einige Beispiele 
mitgeliefert. Aber, die Erfinder von VFX Forth verstehen unter Code¬ 
generator, dass ihr Forth in der Lage ist, aus Forth Statements As- 
semblerbefehle zu erzeugen. Das heiBt, Forth Code soil auf einem 
Microcontroller ausgefuhrt werden. Woher dieser Forth Code stam- 
men soil, verraten sie nicht. In den Beispielen geht es uberwiegend 
urn Windows spezifische Dinge, also das Erzeugen eines Fensters 


Oder das Programmieren eines Webbrowsers. Das mag alles mit VFX 
Forth lauffahig sein, doch eigentlich ist gegenuber gforth kein echter 
Vorteil erkennbar. 

Man kann diese Sache aber noch detailierter beschreiben. Im 
Grunde genommen ist VFX Forth eine Kopie einer C-Compilers. 
Nur eben nicht C->Assembly sondern Forth->Assembly. Der Pro- 
grammierstil zum Entwickeln des Programms ist identisch. Bose for¬ 
muliert wird also das Forth Programm nach den selben Method- 
en erstellt wie das C-Programm auch. Flier wurden die Vorteile von 
Forth nicht ausgenutzt, im Grunde hatte man auch einen normalen 
C-Compiler nehmen konnen. Damit geht die Entwicklung weitaus 
schnelier. Nein, urn Forth richtig auszulasten muss man sich an- 
dere Aufgaben suchen, also welche die nichts mit Windows Program- 
mierung oder embedded zu tun haben, sondern aus dem bereits er- 
wahnten Spektrum der rekursiven Stackmanipulation entstammen. Fli¬ 
er ist eine Aufgabensammlung mit Rekursionsproblemen 7 Eigentlich 
ist das eine Seite, womit die Studenten lernen sollen in Java zu pro¬ 
grammieren, doch Forth eignet sich zur Problemldsung urn einiges 
besser. 

Und es kommt noch besser. Zu den Aufgaben ist dankenswerter- 
weise auch die Losung mit abgedruckt, naturlich ebenfalls in Java. 
Obwohl Java ahnlich wie C eigentlich eine Sprache ist, von der man 
in der Forth Community nicht viel halt, ist in diesem Fall das Beispiel in 
Java ausgezeichnet. In der zweitvorletzten Aufgabe soil man konkret 
Primzahlen rekursiv bestimmen. Die abgedruckte Java-Losung ist ex- 
trem pragnant. Sie ist extrem kurz, nimmt zwei Paameter entgegen 
und lasst sich fast 1:1 in Forth nachprogrammieren. Die Parameter n 
und m legt man einfach auf den Stack, die Syntax passt man leicht an 
und fertig ist das perfekte Forth Program. 

Offenbar geht es also nicht urn Forth vs C sondern worum es geht 
ist die Art der Aufgabenstellung. Man muss ausschau halten nach 
rekursiven Aufgaben und wenn man dort in Java Oder in C eine Lo- 
sung schon hat, kann man diese erstklassig fur Forth nutzen. Ja, ich 
wurde behaupten wollen, dass der Forth Sourcecode in diesem Fall 
sogar eleganter aussieht als die Java Losung. 

Aus diesem Beispiel ist etwas deutlich geworden. Man kann Forth 
so programmieren als ware es C (prozedurale Programmierung), man 
kann Java so programmieren als ware es Forth (rekursive Program¬ 
mierung) oder man kann Forth wie Forth und C wie C programmieren. 
Also die Regel aufstellen dass fur rekursive Aufgaben die einen Stack- 
verwenden nicht Java verwendet werden darf (obwohl das ginge) und 
fur prozedurale Aufgaben wo klassische loop algorithmen eingesetzt 
werden, nicht Forth benutzt werden darf, obwohl auch das geht. 

Primzahlen rekursiv Flier 8 ist nochmal ein Stackoverflow thread 
bei dem mit Python rekursiv Primzahlen bestimmt werden sollen, die 
kurzeste Losung ist die vorletzte, sie ist vergleichbar mit der oben zi- 
tierten Java Losung. Der Sourcecode ist ganz eindeutig Python, ich 
habe mir erlaubt uber Copy&Paste in die obige Abbildung zu uber- 
fuhren. Es ist ein sehr pragnanter Algorithmus und das entschei- 
dene ist, dass er fast 1:1 nach Forth ubertragen werden kann. Klar, 
Forth kennt keinen “def” Befehi und auch kein Print, aber das sind 
Detailfragen. Wichtiger ist hingegen, dass die Aufgabe “Finde eine 
Primzahl rekursiv und bei Verwendung eines Stacks” sehr gut auf die 
Moglichkeiten von Forth zugeschnitten ist. Es ist dasjenige Prinzip, 
wie man Forth richtig programmiert. Also die Sprache genau so ein- 
setzt wie es gedacht war. 

Rekursive Greifplanung Im letzten Abschnitt wurde herausgear- 
beitet, dass sich Forth ausgesprochen gut fur Aufgaben eignet, die 

7 http://www. home, hs-karlsruhe.de/~pach0003/informatik_1/aufgaben/reku rsion.html 

8 https://stackoverflow.com/questions/37095508/how-do-i-find-a-prime-number- 

using-recursion-in-python 
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Algorithmus 1 Primzahl rekursiv 

def is_prime(N, a=2): 
if N <= 1: 
return 

elif a >= N: 
print(N) 

elif N °/. a != 0: 

is_prime(N, a + 1) 
is_prime(23) 


etwas mit Rekursion und mit dem Stack zu tun haben. Es ist gewis- 
sermaBen ein Heimspiel. In der Robotik gibt es zahlreiche Verfahren 
die genau das fordern. So berichtet die Literatur uber rekursive Greif- 
planungsalgorithmen. Wo also die Losung darin besteht, dass sich 
eine Funktion sich selbst aufruft um so den Losungsraum zu durch- 
schreiten. Solche Strategien sind ausgesprochen Forth-friendly. Damit 
ist gemeint, dass sie sich nur schlecht in C aber umso besser auf 
einem GA144 Chipsatz implementieren lassen. Man muss dort nicht 
umdenken Oder an die Maschine anpassen sondern man implemen- 
tiert den Algorithmus genau so wie er gedacht war. 

Um vielleicht beim fruher erwahnten Vergleich mit dem Fixed Gear 
Fahrrad zu bleiben. Es ist so ahnlich als wenn man dem Fixed Gear 
Fahrrad nur dort fahrt, wofur es konstruiert wurde. Auf der Innenseite 
einer Radrennbahn, wo also diese Fahrradkonstruktion nicht aben- 
teuerlich ist, sondern wo sie im Reglement so drinsteht. 

Ein weiteres Problem aus der Spieltheorie ware ein rekursiver 
Backtracking Solver fur Sudoko. Auch dieser lasst sich ausgezeich- 
net in Forth implementieren. Man kann ihn sogar zusatzlich noch par- 
allelisieren und ais Demonstration auf einem GA144 Chipsatz aus- 
fuhren. Diese beiden Beispiele haben gezeigt, dass man Forth am le- 
ichtesten programmieren kann, wenn man sich spezifische auf Forth 
zugeschnittene Aufgaben sucht. 

Ein etwas anspruchsvolleres Beispiel aus der Robotik ware rekur¬ 
sive Natural Language understanding mit DeepLearning. .Es gibt 
dazu mindestens ein Video und ein Paper online was das Verfahren 
erlautert. Und wie sie lieber Leser vermutlich ahnen, eignet sich 
besonders eine Programmiersprache dafur sowas zu implementieren. 
Wurde man das in Forth tun und in einer Forth Zeitschrift publizieren, 
ware das nicht nur Ontopic, sondern ware vielleicht sogar den ersten 
Preis erzielen, weil die Programmiermethode Forth-Style in Reinst- 
form verkorpert. 

4.4 Rekursiver Flood Fill Algorithmus 

Wie die Forth Programmiersprache funktioniert ist bekannt, es gibt 
viele Implementierungen in C und Javascript. Ebenfalls bekannt ist 
wie Forth CPUs funktionieren, die J1 CPU gibt es zum kostenlosen 
Download im Internet. Unklar ist hingegen was man damit anfangen 
soil, genauer gesagt wie man in Forth richtig programmiert. 

Eine Moglichkeit ware es einen C to forth Compiler zu schreiben. 
Auf github konnte ich einen finden, der mit einer Bison Grammar funk¬ 
tioniert. Wahrscheinlich kann man mit Hilfe des LCC Compilern noch 
einen entwickeln der etwas effizienter funktioniert. Dadurch konnte 
man dann vorhandene C Programme auf eine Forth Stackmachine 
konvertieren. Die Frage ist nur: ist das schon richtiges Forth? Aus- 
gefuhrt werden die Programme, aber es fuhlt sich nicht richtig an. 
Nein, wenn man schon Forth verwendet sollte man es auch mit den 
passenden Algorithmen einsetzen. Ein sehr bekannter Algorithmus 
der sich inhaltlich an Forth anpasst ist der rekursive-stackbased flood 
fill Algorithmus. Ein Algoirthmus der exakt so funktioniert wie auch 
Forth funktioniert. Man kann ihn nahezu 1:1 in Forth Code implemen¬ 
tieren. 

Das interessante daran ist, dass man ihn nicht nur in Forth pro¬ 
grammieren kann sondern auch in Standard Java. Der Sourcecode 


sieht dann - obwohl es Java ist - ebenfalis sehr nach Forth aus. Flier 
ist eine Beispielimplementierung 9 welche nicht langer ist als 50 Zeilen 
und in der Einleitung vor einer Stackoverflow Exception warnt. Schaut 
man sich den Code an, so ist das eindeutig Forth Style. Mit diesem 
Code konnte man auch Chuck Moore beeindrucken. 

Offenbar geht es also nicht um die Programmiersprache Java vs. 
Forth sondern worum es geht ist die Art des Algorithmus. Wenn man 
eine rekusrive Stackbased Variante wahlt ist das gleichbedeutend mit 
einem Forth-Style. Also eine Programmiermethode welche kompatibel 
ist zu einem Minimal Instruction Set Computer. Wenn man hingegen 
einen Floodfill Algorithmus auf andere Weise realisiert ist es ein Non- 
Forth Style. 

Warum diese Unterscheidung wichtig ist liegt auf der Pland. Im 
Grunde braucht man sich nicht direkt mit Forth zu beschaftigen wenn 
man etwas uber diese Programmiersprache lernen mochte. Sondern 
Forth ist nur eine Moglichkeit wie man rekursive Flood Fill Algorith¬ 
men implementiert. Genausogut kann man auch Python Oder C ver- 
wenden. Worum es eigentlich geht das ist die Rekursion, also eine 
besondere Form der Programmierung die man auf einem Computer 
anwendet um Probleme zu Ibsen. 

Und hieruber erhalt man auch eine Antwort wie man C-Programme 
richtig nach Forth konvertiert. Es reicht nicht einfach nur einen Com¬ 
piler zu verwenden, sondern man muss den Algorithmus rekursiv 
definieren. 

In der Informatik wird Rekursion unter dem Stichwort L-System 
und kontextfreie Grammatiken untersucht. Ein Lindenmayer-System 
ist harmlos es wird nur zur Darsteliung von Bildern eingesetzt. Aber 
was ware wenn nicht Bilder sondern Algorithmen das Ziel ist, das L- 
System also ein Programmablaufplan darstellt? Dann haben wir es mit 
Fraktalen Automaten zu tun, was in Richtung Super-Turing-Maschinen 
geht. Man hat eine sehr allgmeine Grammatik die ausfuhrbaren Code 
erzeugt der wiederum ein Problem lost. Die Frage ist jetzt wie muss 
die Grammatik aussehen um konkrete Aufgaben zu Ibsen? 

Eine konkrete Vorsteilung wie sowas praktisch realisiert wird hat [5] 
Es geht in dem Paper um kontextfreie Grammatiken um Baumartige 
Algorithmen auszubilden. Ahnlich wie bei den L-Systemen werden 
hierarchiche Strukturen erzeugt, nur dass sie diesmal ausfuhrbaren 
Code darstellen. Auf Seite 7 ist eine Abbildung zu sehen die das 
ganze in Aktion zeigt. Oben ist eine relativ simple Produktionsgram- 
matik abgedruckt und darunter der Baum der durch diese generiert 
wird. Ein bisschen erinnert das ganze an den Quatsch-Generator Sci- 
gen womit man Texte erstellen kann die so aussehen als waren sie 
von einem Wissenschaftler erstellt worden. Auf den Einsteiger mo- 
gen solche Ansatze wie Voodoo erscheinen, also eine komplett abge- 
drehte Spielart in der Informatik darstellen, also ein Randthema was 
sich weit auBerhalb des Mainstreams befindet. Doch fragt man ein- 
mal Google was es sonst so uber “"Tree Based Genetic Program¬ 
ming" weiB, so finden sich fast 1000 Paper zu der Thematik. Und 
wenn man den Problemkreis etwas erweitert sind noch viele weitere 
Veroffentlichungen sichtbar. Kurz gesagt, das ganze ist keineswegs 
ein Randthema, sondern ein umfassend erforschtes Thema was man 
als langweilig bezeichnen darf. 

Die Idee dahinter ist simpel: es geht darum, nicht selber zu Pro¬ 
grammieren, sondern stattdessen mathematische Algorithmen zu 
erfinden die Metaprogrammieren erlauben. Also eine Grammar zu 
bauen, die Programme erzeugt, die andere Programme uberprufen 
um so am Ende eine Programmsynthese zu erreichen. Der Software 
gibt man als Input die Aufgabe wie “bewege den Roboter ins Ziel” 
und tiber einen rekursiven tief-verschachtelten stackbased Algorithm 
wird dann eine Losung generiert. Ungefahr das ist es was die Autoren 
anstreben, damit vertrodeln sie ihre Zeit. Ja anders kann man es nicht 
bezeichnen weil ein praktischer Nachweis der Realisierbarkeit steht 

9 http://www.cis.upenn.edu/~cis110/13fa/hw/hw08/FloodFill.java 
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noch aus. Ublicherweise wird die Grammar oder die Rekursiven Al- 
gorithmen keiner praktischen Evalution unterzogen beispielsweise in 
Roboterwettbewerben. Es sind nichts anderes als groBenwahnsinnige 
Konzepte die in einem wissenschaftlichen Paper utopische Vorstellun- 
gen vermitteln. Die Botschaft lautet im Kern, dass man das Program- 
mieren selbst an die Maschine verlagern kann, also eine Maschine 
dazu zu bringen sich selbst zu verbessern. 

Gegenmodell Rekursive Algorithmen inkl. der Erweiterung des Ge¬ 
netic Programming sind nichts neues in der Geschichte der Infor- 
matik. Sie hatten ihre Blutezeit in den 1960-1970'er Jahren als er- 
stmals die Chaostheorie mathematisch beschrieben wurde und die 
ersten Computerprogramme entwickelt wurden, welche das ganze 
auf die Informatik ubertragen haben. Im Grunde sind heutige Pa¬ 
per nichts anderes als aufbereitete Informationen die schon damals 
bekannt waren. Interessanterweise gab es in den 1970'er zu genau 
dieser Form von kunstlicher Intelligenz eine Gegenbewegung. Sie 
wurde iniitiert von J.C.R. Licklider der sich weniger als Mathematik- 
er wie Donald E. Knuth verstand sondern sich in den geistes- 
und sozialwissenschaften zu Hause fuhlte. Licklider wollte keine 
kontextfreien Grammatiken erstellen die Computerprogramme syn- 
thetisieren sondern Licklider hat die Idee einer Mensch-Maschine- 
Schnittstelle propagiert. Genauer gesagt hat er das Intergalactic Net¬ 
work, besser bekannt als Internet erfunden. 

Wahrend bei rekursiven Grammarbasierenden Suchalgorithmen 
die Ausgabe von mathematischen Algorithmen und kurzen Codeseg- 
menten im RAM des Computers erzeugt werden besteht bei einem 
Rechnerverbund der Fokus auf den Nutzereingaben der Menschen. 
Das Internet zeigt genau das an, was irgendwo auf der Welt in ein Ter¬ 
minal eingegeben wurde. Licklider hat ruckblickend die richtige Vision 
gehabt, seine Idee hat sich durchgesetzt, das rekursive genetic based 
Programming dagegen nicht. Anders formuliert, es nicht moglich mit 
einigen simplen mathematischen Formeln eine hohe Komplexitat zu 
erzeugen. Ein Fraktal mag dynamisch aussehen so als ob da verbor- 
gene Strukturen enthalten sind die man genauer untersuchen kann 
doch die darin enthaltene Entropie ist nur scheinbar hoch. Machen wir 
es konkreter: Angenommen man hat ein hochkomplexes Fraktal vor- 
liegen in 10000x10000 Pixeln, dann kann man dieses komprimieren 
auf die Erzeuger-Formel, also jenen Algorithmus womit es generiert 
wurde. Dieser Code war nur 5 kb grol3. Anders formuliert, so komplex 
wie gedacht ist das Farbenspiel nicht, sondern 5 kb ist nicht mehr als 
eine Strophe von einem Gedicht. 

4.5 Genetic Programming 

Anfangs glaubt man vielleicht dass rekursive Algorithmen, Chaosthe¬ 
orie und Erzeugergrammatiken etwas sehr machtiges und wenig er- 
forschtes Thema seien zu dem man unbedingt mehr erfahren musste 
weil davon die Zukunft der gesammten Menschheit abhangt, doch 
wenn man einmal Google Scholar fragt was es uber “genetic Pro¬ 
gramming” schon heute weiB so findet sich erstaunlich viel Material 
zu diesem Thema. Nicht weniger als 134000 Paper werden angezeigt 
die allesamt in angesehenen Fachzeitschriften veroffentlicht wurden. 
Wenn man weiB, dass uber alle Wissenschaften hinweg es weltweit 
nicht mehr als 50 Mio Paper gibt dann ist das eine ganze Menge 
(0,268% genau gesagt). Selbst uber ein sehr bekanntes Thema wie 
Keuchhusten (whooping cough) gibt es nur halb so viele Paper. 

Allein im Jahr 2017 sind bereits 4500 Paper zu “genetic program¬ 
ming” erschienen und das Jahr ist nochnichtmal vorbei. Es wird in sehr 
vielen Kontexten verwendet und offenbar glauben die Autoren, dass 
es echte Wissenschaft ware. Ein bisschen abgedreht aber mathema¬ 
tisch fundiert. Und genau das scheint das Problem damit zu sein, das 
ganze ist eben keine absonderliche Theorie von AuBenseitern son¬ 


dern offenbar Ausdruck eines Selbstverstandnis. Wer sich irgendwie 
zugehorig fuhlt zur Informatik veroffentlicht ein Paper uber dieses The¬ 
ma. Leider ist inhaltlich das ganze nicht beosnders ergiebig. Es wurde 
bereits alles daruber gesagt, und das sich daraus neue Anwendungen 
ergeben ist unwahrscheinlich. Die hohe Anzahl der Paper verrat eher 
wie sich die akademische Informatik selber versteht. Und zwar mochte 
man sich gegenuber dem stupiden Programmieren abgrenzen. Echte 
Software mit C oder Java zu schreiben, das ist etwas was die Studen- 
ten machen und vielleicht noch Linus Torvalds, wir jedoch die echten 
Informatiker an den Plochschulen schreiben Codegeneratoren. Also 
Programme mit denen sich andere Programme erstellen lassen, wir 
stehen oben auf dem Berg und die anderen sind von uns abhangig, 
so jedenfalls die Ideologie. 

Aber welcher Nachteil entsteht genau wenn man keine Genetic 
Programming Paper und keine dementsprechende Software besitzt? 
Dann ist man zuruckgeworfen auf seine IDE wo man in Java oder ein¬ 
er anderen Sprache manuell etwas programmiert und sich via github 
Anregungen holt wie es besser geht. Aber ist das wirklich eine Ver- 
schlechterung? Ist nicht vielmehr die manuelle klassische Program- 
mierung das worum es wirklich geht? Ja ich wurde sogar noch eine 
Stufe weiter gehen und “genetic Programming” mit dem Unsinnsgen- 
erator Scigen vergleichen wollen. In beiden Fallen wird die Erstel- 
lung von Content an eine Maschine verlagert und in beiden Fallen 
ist das Ergebnis kompletter Unfug. Es macht zwar SpaB sich damit 
zu beschaftigen, es ist lustig sein Gegenuber zu verappeln, aber es 
bringt die Wissenschaft nicht weiter. 

Anders formuliert, Genetic Programming ist keineswegs hardcore 
Informatik die anstrengend ist, sondern es ist ein Thema mit man sich 
gerne und zur Entspannung beschaftigt. So ahnlich wie Physiker wenn 
sie schon leicht angetrunken sind, auch mal naher uber ein Perpetum 
Mobile diskutieren oder sogar behaupten eines gebaut zu haben was 
sie aber nicht vorfuhren weil das Patent noch nicht beantragt wurde. 

Warum diese Dinge so beliebt sind hat etwas mit den sozialen 
Rollen zu tun innerhalb derer sich Wissenschaftler befinden. Die 
Gesellschaft erwartet von einem Physiker im Grunde, dass er ein 
Perpetum Mobile erfindet. Weil so eine Maschine genau das ist, was 
alle wollen. Und en Informatiker soli doch bitteschon Metaalgorithmen 
erfinden die sich selber programmieren. Insofern sind die Paper uber 
dieses Thema der Versuch den Rollenerwartungen gerecht zu wer¬ 
den. Genauer gesagt mit jenen Rollenerwartungen welche Informatik¬ 
er entdeckt haben. 

Als Negativ-Beispiel mochte ich das Paper [1] zitieren. Es ist gerade 
in diesem Jahr erscheinen und kann als typisch gelten. Es geht darum 
urn Genetic Programmierung auf einer Two-Stack GPU Grafikhard- 
ware. In dem Paper enthalten sind Literaturlisten, Algorithmen und 
Tabellen. Ferner gibt es noch Erlauterungen wie das Projekt durchge- 
fuhrt wurde. Die Autoren glauben offenbar, dass jemand da drauBen 
diese Anforderungen an die Informatik gestellt hat, und die Autoren 
liefern jetzt. Aber will die Gesellschaft wirklich derartige Algorithmen 
haben, bringt das die Dinge voran? Zunachst einmal ware es sicher- 
lich toll, wenn man damit komplexe leistungsfahige Software gener- 
ieren konnte. Also schon mit Grafikkarten von nvidia und ein wenig 
Plokus pokus Software automatisch erzeugen, verifizieren und auf 
Realen Systemen deployen. Doch leider zeigt die Erfahrung dass es 
so nicht geht. Das ganze erinnert doch stark an ein Perpetum Mobile 
wo nicht Erkenntnis sondern Aberglauben das Ziel ist. 

5 Hardware 

5.1 Traumcomputer GA144 

Der GA144 wird manchmal als Superchip bezeichnet. Seine Faszina- 
tion erklart sich daraus, dass heute ubiche PCs und Microcontroller 
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rund 2 MIPS je Milliwatt (Million instructions per seconds) benotigen, 
der FI 8 Chip aus dem der GA144 besteht jedoch 155 leistet. Woran 
das liegt ist simpel: Stackmachine plus Clockcless CPU plus fehlen- 
der Microcode = supereffizienter Microchip. Es bleibt nur ein Problem. 
Wie programmiert man diesen Chip? Einen Einstieg liefert 10 dort wird 
das ubliche Marchen vom schlanken Forth verbreitet, dass es also nur 
zwei-drei Register gibt einen Instruction Pointer und ganz wenig Forth 
Kommandos. Nur das ist nicht die voile Wahrheit. So wie in dem Di- 
agramm gezeigt funktioniert der Chip nicht. Eigentlich ist es sehr viel 
komplizierter. Und zwar muss man zuerst einmal Mono-Develop bei 
sich installieren, dann noch f-sharp und dann ontop den GA144 Sim¬ 
ulator. Als “simple” wurde ich das nicht bezeichnen eher als Schw- 
ergewicht mit massiver Oberiadung. 

Was in der Anleitung leider nicht thematisiert wurde, und wo ich 
ebenfalls passen muss ist die Frage wie man auf dem GA144 Chip ein 
Computerspiel startet wie z.B. OpenRA. Der mitgelieferte RAM Plaupt- 
speicher reicht jedenfails nicht aus urn Windows 10 zu booten. Er be- 
tragt magere 2 MB. Das ganze lasst viele Fragen unbeantwortet, aber 
vielleicht will ich auch gar nicht wissen wie man OpenRA auf dieser 
Plollenmaschine spielt? Hoffentlich hat das nichts mit neuronalen Net- 
zen zu tun, das ware nicht gut. 

Ich sage hoffentlich, weil es irgendwie auf der Eland liegt. Neuronale 
Netze durften ungefahr das sein, was Chuck Moore als sourceless 
Programming definiert hat, also Software die man nicht programmiert 
sondern irgendwie von alleine da ist. Ferner basieren Neuronale Net¬ 
ze auf Rekursion und sie benotigen schnelle Plardware. 

Auf der Euroforth 2016 Tagung hat jemand ein rekurrentes Neu- 
ronales Netz vorgestellt was in 900 Lines of Code in Forth program¬ 
miert wurde. Wurde man das auf den GA144 Chip portieren hatte 
man einen leistungsfahigen Neurocomputer. Da ich mich ein wenig mit 
neuronalen Netzen beschaftigt habe, kann ich dazu ein wenig mehr 
erzahlen. Die Kurzfassung lautet: es bringt nichts. 

Die Langfassung: von den Leistungsdaten ist ein GA144 Chip rund 
50x energieeffizienter als ein normaler Chip der in C programmiert 
wurde. Das heiBt, wenn man den Computer mit 10 Watt betreibt ist 
er 50x schneller als ein normaler Computer. Das neuronale Netz al¬ 
so seine Fahigkeit sich an externe Muster anzupassen funktionert so 
wie es auch neuronale Netze auf normalen PCs tun. Wir erhalten al¬ 
so eine Neuronalen Netz Simulator der leicht effizienter arbeitet als 
gewohnlich. Leider bringt das null Vorteil. Es wird nicht gelingen damit 
auch nur simple Mathematische Gleichungen wie z.B. Primzahlen zu 
lernen. Der praktische Nutzen ist gleich Null. Trotzdem rate ich explizit 
dazu, das einmal auszuprobieren. 

Also schon mit Forth ein neuronales Netz auf einem GA144 
schreiben, dass dann auf 100% CPU Load hochfahren und dabei 
zuschauen wie die Lernschritte durchlaufen. Zu Anfang wird das neu¬ 
ronale Netz seinen Fehlerwert senken und man hat den Eindruck, als 
ob es gut funktioniert, doch irgendwann wird sich der Errorwert ein- 
pendeln und dann passiert gar nichts mehr. Unverandert laufen die 
Cores auf maximum Auslastung ohne dass das neuronale Netz sich 
weiter verbessert. Das heiBt in der Realitat dass es nicht in der Lage 
ist, eine Reihe mit Primzahlen fortsetzen Oder bei einer inversen Kine- 
matik die Zielkoordinaten zu bestimmen. 

Ja wurde man die Geschwindigkeit des Systems nicht nur urn 
den Faktor 50 sondern urn den Faktor 50000 erhohen, wurde das 
neuronale Netz immernoch nicht lernen. Es ware in einem so- 
genannten lokalen Minimum gefangen und ist nicht der Lage die 
Gewichte so zu optimieren, dass die Trainingsdaten verknupft wer- 
den. Das Phanomen mit ist bekannt aus neuronalen Netzen die auf 
herkomlicher Plardware entwickelt werden, und es tritt auch bei nvidia 
Grafikkarten, Supercomputer, Forth Chips und sogar bei optischen 


10 https://blogs.msdn.microsoft.com/ashleyf/2013/10/13/programming-the-f18/ 


DSP Chips auf. Anders formuliert, so kunstliche Intelligenz erzeugen 
zu konnen hat von der Praxis keine Ahnung. 

Man kann nicht nur den GA144 verwenden urn neuronale Netze 
zu simulieren, sondern das ganze gleich als FPGA aufbauen, also 
nicht mit der Forth Programmiersprache dazwischen sondern die Ler- 
nalgorithmen direkt im FPGA synthetesieren. Die Effizienz des Chips 
ist dann noch etwas hoher und es gibt mehrere Paper wo das aus- 
fuhrlich beschrieben wird. Nur, auch das ist Pseudoscience, weil die 
Autoren nicht willens Oder nicht fahig sind das ganze als Failed Project 
zu betrachten. Sie glauben sie mussten das Thema unter didaktis- 
chen Punkten jemanden erklaren und das wurde sie davon befreien 
die Schwachen bloBzustellen. 

Selbst Projekte die halbwegs serios daherkommen, beispeilsweise 
wenn man Convolution Neural Networks zur Bilderkennung in einem 
FPGA einprogrammiert, sind objektiv betrachtet Zeitverschwendung. 
Wurde man die Bildparser ohne Neuronales Netz sondern als Script¬ 
ing Al in Java programmieren, ware es urn einiges effizienter. Neu¬ 
ronale Netze und hocheffiziente Stackmaschinen sind nichts anderes 
als eine Modeerscheinung die Konkunktur hat, weil es alle so machen. 

Schauen wir uns den GA144 Chip genauer an, genauer gesagt das 
Entwicklerboard auf dem er sich befindet. Der Hauptkritikpunkt ist der 
winzige RAM. Auf dem Chip selber ist nur der Stack verbaut, extern 
auf dem DEveloperboard befinden sich 2 MB Ram. Viel zu wenig fur 
eigene Programme erst recht nicht fur ein Betriebssystem. Wollte man 
einen halbwegs ordentlichen Rechner haben, kann man ruhig einen 
altersschwachen Intel Atom Prozessor nehmen aber dem dann 1 GB 
RAM spendieren. Dort ladt man Linux hinein und ontop noch eine 
Bilderkennungssoftware die 10 MB an Sourcecode mitbringt. Man er- 
halt daruber ein extrem leistungsfahiges System, und das obwohl oder 
gerade weil die CPU ineffizient ist und die Plardware fast nichts kostet. 

Es handelt sich urn eine Kuriositat innerhalb der Informatik. Auf der 
einen Seite werden riesige Forchungsprojekte durchgefuhrt bei de- 
nen neuronale Netze in driverless Cars, und zur Steuerung von OP- 
Robotern im Krankenhaus eingesetzt werden, auf der anderen Seite 
fragt niemand ob neuronale Netze uberhaupt in der Lage sind, auch 
nur Primzahlen zu erkennen. Also die Frage “ist 113 eine Primzahl?” 
korrekt zu beantworten. Neuronale Netze konnen diese Frage nicht 
beantworten. Und der Grund warum das niemandem auffallt und die 
Frage danach bereits an Blasphemie grenzt wirft kein gutes Licht 
auf das Wissenschaftssystem. Kennzeichen von Protowissenschaft 
ist es, dass zwischen Magie und Rationalitat nicht konsequent unter- 
schieden wird urn so die sozialen Rollen stabil zu halten. 


Primzahlen Vielleicht an dieser Stelle ein kleiner Exkurs zu 
Primzahlen. Das hat nichts mehr mit Forth zu tun, aber egal. An¬ 
ders als ublicherweise in den Online-Foren und in den Vorlesungen 
hat keinerwegs der Fragesteller der wissen mochte ob man mit Neu¬ 
ronalen Netzen Primzahlen testen kann irgendwas nicht richtig ver- 
standen, sondern es liegt an der Informatik diese Frage zu beant¬ 
worten. Die Erklarung lautet, dass erstens neuronale Netze keine 
turing-machtigen Maschinen sind, also gegenuber manuell program- 
mierten C-Code unterlegen sind. Das war auch damals schon beim 
xor Problem der Fall, und convolutional Neural Networks haben 
lediglich die Grenzen des moglichen leicht verbessert. Und zweit- 
ens, selbst wenn neuronale Netze all das konnten was auch Source- 
code in C kann, wurde es dann noch immer nicht funktionieren. Weil, 
auch beim genetic Programmierung wo eine Turing-machtige ’Mas- 
chine evolviert wird, ist es nicht moglich Primzahltest-Programme zu 
erzeugen. Rein theoretisch schon, nur leider wurden ca. 1 Mio Jahre 
vergehen bis man das passende Program im Godelraum gefunden 
hat. 
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5.2 Hardware-Rezension 

Der leichteste Einstieg in Forth besteht darin, es als Programmier- 
sprache zu betrachten. Bei Repl.it gibt es einen Online-Interpreter, 
man kann aber auch gforth nutzen um kleinere Forth Programme 
laufen zu lassen. Fur den C-64 gibt es eine Forth Distribution namens 
Durexforth. Allen Forth Implementierungen gemeinsam ist, dass sie 
Forth-Worter auf Machinencode mappen. Anders als bei einem C- 
Compiler wird der Code nur interpretiert, was dazu fuhrt, dass die 
Geschwindigkeit ahnlich langsam ist als wenn man Python verwen- 
det. Das heiBt, Forth ist mindestens 3x langsamer als wenn man C 
verwendet. 

Will man die maximale Performance haben, muss man einen Forth 
Microcontroller verwenden. Flier wird es schon etwas schwieriger, weil 
es soviele Forth Chips nicht gibt. in den 1980’er war die Novix Baurei- 
he beliebt, die aber auBerhalb der Forth Community niemand verwen¬ 
det hat. Eine aktueile CPU ist die GA144 welche zusammen mit einem 
Entwicklerboard 450 US$ kostet. Laut der Anleitung ist darauf auch 
ein Steckplatz fur SRAM Chips enthalten, so dass man den Haupt- 
speicher erweitern kann. 11 Ob das so stimmt und wie man das Board 
n der Praxis einsetzt weiB ich leider nicht. Es gibt nur wenige Blog- 
postings von Leuten die es verwenden und auch Youtube Videos sind 
selten. Das Problem sind wohl weniger die 450 US$ fur das Evalu¬ 
ation Board inkl. Forth Chip, sondern das Problem durfte sein, dass 
die Plattform komplett anders ist als normale Microcontroller. Eines ist 
jedenfalls sicher, mit dem GCC Oder mit LLVM kann man dafur keinen 
Maschinencode erzeugen. Jedenfalls nicht out-of-the-box. 

Rein von den Leistungsdaten sind Forth Chips wohl unglaublich 
schneli. Uber die Novix Chips in den 1980'er wurde hinter vorgehal- 
tener Hand erzahlt, dass sie schneller seien ais jede andere Micro¬ 
controller und das selbe wird uber den GA144 Prozessor gesagt. Laut 
den Leistungsdaten ist die Maschine extrem flott. Das Problem ist 
auch hier wieder weniger die nackte Leistung als vielmehr die Frage 
ob man damit klarkommt. Weil, selbstverstanlich muss man die Forth 
Programmiersprache beherschen sonst wird es nicht. Zu Forth gibt 
es leider keine guten Einfuhrungsbucher und auf Deutsch schonmal 
gar nicht. Die Lage ist am ehesten vergleichbar mit Ende der 1970’er 
Jahre als der neue Altair PC gerade vorgestellt wurde, und eine Hand- 
voll Bastler damit herumgespielt hat, lange bevor es die ersten Firmen 
gab die es auf eine professionelle Ebene gehoben haben. 

5.3 Arduino an der Fernbedienung 

Die einfachste Methode um Roboter jeder Art zu steuern beste¬ 
ht darin, dass man an einen Arduino Kleinstcomputer eine analoge 
Fernbedienung anschlieBt. Das ist alles. Damit lassen sich sowohl re¬ 
mote Cars, remote controlled micromause Oder UAVs steuern. Das 
Prinzip entspricht ungefahr dem was als Minimal-Forth System bekan- 
nt. Dort wurde leicht im Scherz vorgeschlagen dass man nur zwei Be- 
fehle implementiert und das System aus der Feme steuert. Genau 
dieses Konzept funktioniert ausgezeichnet. Es bedeutet, dass man 
sich die Basteiieien mit dietlibc Biblitotheken, GCC fur embedded, 
echtzeitfahige Microkernels und Assemblerprogrammierung komplett 
sparen kann,sondern Elektronik komplett analog ausfuhrt. Das heiBt 
sie so nutzt wie es in den 1950'er Jahren ublich war. Das heiBt, die 
Micromouse besteht aus einem Analogen Schaltkreis und der wird 
mit dem Arduino gekoppelt. Vom Arduiono aus geht es dann weiter zu 
einer Workstation wo High-Level-Programme in C# und Python laufen. 

Selbstverstandlich reicht die Prozessorleistung eines Arduinos 
nicht aus, um damit Roboter zu steuern. Ja es lauft nochnichtmal 

11 Laut der Anleitung http://www.greenarraychips.com/home/documents/greg/DB003- 
110926-EVB001.pdf Seite 6 kann man einen 2 MB RAM Baustein und einen 1 MB 
Flash Baustein direkt an das Eval Board anschlieGen. 


ein Betriebssystem darauf, so langsam ist die Hardware. Aber dafur 
wurde der Arduino auch nie gebaut. Er soli einfach nur ein WLAN Sig¬ 
nal was von einer Workstation stammt an einen anlogen Schaltkreis 
weiterleiten. 

6 Compiler friendly 

6.1 Microcontroller 

Einen ungewohnlichen aber brauchbaren Ansatz um Microcontroller 
miteinander zu vergleichen liefert 12 Dort steht nicht etwa die Leis¬ 
tung der CPU im Mittelpunkt sondern es wird gezielt nach der 
“Compiler friendly”ness gefragt. Also wie leicht sich mit einem 
Standard-Compiler wie GCC dafur Code erzeugen lasst. Interessan- 
terweise unterscheiden sich die Microcontroller hier betrachtlich. Bei 
lobenswerten Systemen wie dem MSP430 ist die Unterstutzung mit 
C-Compilern vorbildlich, wahrend andere Systeme wie die PIC Mod- 
ellreihe haufig Probleme verursachen. In der Art, dass man entweder 
einen kommerziellen Compiler dazu kaufen muss, Oder man nicht in 
C sondern in einer Sprache programmiert Oder im Extremfall dass es 
uberhaupt keine Compiler gibt und man Forth bemuhen muss. 

Der Fokus auf die Unterstutzung durch C-Compiler ist wichtig, wenn 
man plant die Gerate tataschlich irgendwo zu nutzen, also damit einen 
Roboter zu bauen. Das heiBt, nicht der controller an sich steht im Mit¬ 
telpunkt und wie schon doch die LED Lampen blinken sondern wo- 
rum es geht ist das Ausfuhren von Software. Das heiBt, der MSP430 
wird instrumentalisiert und nur als Teil eines groBeren Systems betra- 
chtet. Genauer gesagt eines Hardware-Projektes bei dem der Micro¬ 
controller nur eine Komponente unter vielen ist. 

Als noch verbreiterter gilt der AVR Microcontroller. Dieser lasst 
sich sehr leicht in C-Programmieren und die Auswahl an Beispielpro- 
grammen und durchgefuhrten Projekten ist immens. Man kann daraus 
ableiten, dass eine gute Unterstutzung durch OpenSource C-Compiler 
das wichtigste Krieterium ist ob sich ein Microcontroller im Massen- 
markt bewahrt. Also wie beliebt er bei den Kunden ist und wieviei sie 
damit anfangen konnen. Zum AVR Controller gibt es sogar eine Com- 
puterclub2 Sendung wo das Thema sehr einsteigerfreundlich aufbere- 
itet wird. 

Das interessante ist, dass auf der Plattform Microcontroller.net es 
relativ viel Interesse an Forth gibt. Meist von Leuten die Standard- 
AVR Controller schon ausprobiert haben, dafur in C auch kleine Hello 
World Programme geschrieben haben und jetzt Lust haben fur neues. 
Sie wahlen bewusst oder unbewusst einen compilerunfrinedly Micro¬ 
controller der sich nur in Forth programmieren lasst und schauen dann 
einfach mal wie weit sie damit kommen. 

Interessant ist dann auch die Diskussion in dem Forum zu 
beobachten. Im Regelfall versuchen die Leute zuerst mit Forth 
klarzukommen, dann versuchen sie das Forth mehr in Richtung C zu 
trimmen. Ublicherweise geht das nicht. Der Fehler den sie machen ist 
es, mit Forth Probleme losen zu wollen die sonst mit C gelost wer- 
den. Also anwenderorientiert zu denken. So nach dem Motto: mein 
Linefollowing Algoirthmus soil nicht auf einem AVR Microcontroller in 
C programmiert werden sondern auf einem stackbasierenden Micro¬ 
controller in Forth. Wie mache ich das? 

Die Antwort lautet: gar nicht. Um Forth zu verstehen muss man sich 
Probleme suchen, fur die Forth konzipiert wurde, also rekusriv Prob¬ 
leme die einen Stack erfordern. Ein guter Anfang ist es, den Roboter 
so zu programmieren dass er sich wie ein rekursiver Floodfill Algorith- 
mus verhalt. Also schon ein Lsystem aufmait. Oder noch besser, ein 
rekursives neuronales Netz zu verwenden um das System komplett 
autonom zu gestalten. Das ist dann echtes Forth. 

12 https://www. mikrocontroller.net/articles/Mikrocontroller_Vergleich 
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Will man derartige Microcontroller streng nach Forth-Style pro- 
grammieren muss man ein Konzept wahlen was als “Neuromorphic 
Microcontroller” bekannt ist. Ein Verfahren was neuronale Netze, 
rekursion und Stackbased Memory miteinander kombiniert. 

Forth ist die ideale Sprache wenn man neuronale Netze imple- 
mentieren mochte. Der Grund ist dass Forth auf Stackmachinen ex- 
trem effizient ausgefOhrt wird und das Forth Programme naturgemaB 
sehr kompakt sind. Die Funktionalitat wird nach dem Starten des Pro- 
gramms entfaltet und passt sich adaptiv an die Umgebung an. Man 
kann sagen, dass C-Programmierer die Losung zum Ziel in Form von 
Ablaufplanen und UML Diagrammen erarbeiten wahrend Forth Pro- 
grammierer ihr superkurzes Neural Network starten und die Machine 
dann autonom agiert. Die Kombination aus Forth plus Neuronalen 
Netzen ist ideal wenn man eine magische Vorstelung von Maschinen 
besitzt wonach man sich nur etwas zu wOnschen braucht was dann in 
Erfullung geht. Ein forth-basierendes neuronales Netz ist vergleichbar 
mit einem Perpetuum Mobile: es ist unglaublich einfach aufgebaut, 
es ist komplett anti-Mainstream und es ist Ausdruck eines Trends hin 
zu Neureligiosen Newage Bewegungen wo das personliche Empfind- 
en im Mittelpunkt steht und etablierte Wissenschaft nicht langer im 
Fokus steht. Der Forth way of live bedeutet, dass man Rationalitat 
ablehnt und stattdesen komplette Anarchie pflegt. Also die Rebellion 
ins Zentrum stellt und nach Sinn sucht den das rationale Denken nicht 
erfullen kann. 


AVR Microcontroller Jetzt stellt sich die Frage warum es aus- 
gerechnet Forth und neuronale Netze sein mussen. Zur Erinnerung: 
man kann Microcontroller auch normal programmieren. Man sucht 
sich einfach einen c-friendly Compiler wie den AVR heraus, schreibt 
sein Programm in C und spielt es auf den Chip. Der Weg dorthin ist 
simpel, Fehler sind unwahrscheinlich. Man kann daruber eine sehr 
preiswerte Entwicklungspipeline von einer Idee zu einem funktions- 
fahigen Roboter realisieren. Er basiert auf Standard-Komponenten 
wie der genannten Plardware plus OpenSource C-Compiler welche 
umfassend dokumentiert sind und mit zahlreichen Beispielen im Inter¬ 
net. 

Die Nutzung von Altenativen dazu genauer gesagt Forth in Kom- 
binination mit Neuronalen Netzen und rekurrentem Memory ist hinge- 
gen etwas auBergewohnliches. Von den okonomischen Kosten her 
gesehen ist es viel zu teuer urn damit in vertretbarer Zeit ein 
Ziel zu erreichen, man wird also am Ende keinen funktionsfahi- 
gen Roboter vorweisen konnen. Eine Moglichkeit die Kosten zu 
senken gibt es nicht. Weil die Nichtverfugbarkeit von Forth Tutori¬ 
als, die Nicht-Verfugbarkeit von C-Compilern fur PIC Microcontroller 
und die nicht-wiederholbarkeit von neuronalen Netz Experimenten 
ist eine Tatsache. Sie fuhrt dazu, dass die gewohnte Engineering 
Pipeline ins Leere lauft man sich also mit sich selbst beschaftigt 
und das eigentliche Ziel aus den Augen verliert. Vermutlich ist das 
der Grund warum, sich einige Leute fur Forth und Neuronale Net¬ 
ze stark machen, weil sie mit dem gewohnten C-basierenden Engi¬ 
neering nichts anfangen konnen, weil sie nicht gewohnt sind Algorith- 
men zu entwickeln weil sie keine funktiorenden Roboter anstreben. 
Uberlicherweise enden Forth Projekte mit dysfunktionaler Software, 
also mit Robotern die nicht im Ziel ankommen, Betriebssysteme die 
nicht booten und Primzahlprogrammen die nicht funktionieren. Gle- 
iches gilt fur rekurrente Neuronale Netze. Insofern ist es sinnvoll 
diese Anti-Technologie zu kombinieren so bleibt es wenigstens uber- 
schaubar und die C-Programmierer konnen sich mit echten Algorith- 
men beschaftigen wo sie richtige Probleme losen. 


6.2 Forth vs Rest der Welt 

Zwischen Forth und Mainstream gibt es einen gewaltigen Unter- 
schied. Schauen wir uns zunachst ein Buch uber den AVR Micro¬ 
controller an. Ich brauche hier keinen konkreten Titel zu nennen es 
gibt mehrere gut geschriebene sogar auf Deutsch. Ublicherweise ste¬ 
ht in solchen Buchern das Projekt im Fokus. Meist wollen die Leser 
wissen wie man einen Roboter baut urn beim Micromouse Wettbe- 
werb teilzunehmen. Und die dazu notigen Kenntnisse werden in dem 
AVR Buch vermittelt. Es wird der Microcontroller selber beschrieben, 
es wird erklart wie man mit GCC dafur ein Programm erstellt, welche 
Variablen dort enthalten sind, wie man das auf die Plardware drauf- 
spielt und den Code verandert. Manchmal gibt es noch einige Basisal- 
gorithmen wie Pfadplanung und Steering so dass man der Lekture 
gleich anfangen kann mit seinem eigenen Plobbyprojekt. Es handelt 
sich also urn einen produktiven aufwartsgerichteten Lernprozess der 
an einem Ziel ausgerichtet ist und es ublicherweise auch erreicht. 

Jetzt schlagen wir ein Buch Ober Forth auf. Davon gibt es nicht so 
viele. Im Regelfall ist man dort nicht auf konkrete Projekte fokussiert 
sondern erklart erstmal was eine umgekehrte Polnische Notation ist. 
Dann erfahrt man dass man umdenken muss und sich einen Stack 
vorstellen muss, weil es sonst nicht geht mit der Programmierung. 
Dann wird noch kraftig uber C-Compiler abelastert weil die ange- 
blich ineffizient waren. Eine Auflistung uber vorhandene Forth Bib- 
liotheken mit denen man gleich losprogrammieren kann fehlt natur- 
lich, stattdessen wird ausschweifend erklart, dass sich jeder seine 
eigene Software from scratch schreibt weil das effizienter ware und 
die Plardware besser auslastet. Aha, und irgendwas konkretes Anfan¬ 
gen lasst sich mit dem Wissen auch nicht, es sei denn man fuhlt sich 
berufen Forth weiterzuempfehlen und eigene Paper zu diesem Thema 
zu schreiben. 

Aber wie kommt eigentlich der fundamentals Unterschied zwischen 
Forth und dem Rest der Welt zustande? Nun, ein AVR Microcontroller 
und der passende C-Compiler wurden entwickelt urn die Dinge vo- 
ranztubringen also in Projekten konkrete Ergebnisse zu erzielen. Es 
geht darum, auBere Anforderungen einzuhalten und funktionsfahige 
Plardware plus Software zu liefern. Es sind Systeme fur den Praxi- 
seinsatz und dementsprechend ist auch das Entwicklungsmodell. Bei 
Forth hingegen geht es urn das genaue Gegenteil. Es geht bei Forth 
niemals darum Roboter zu bauen, Software auszuliefern oder das 
Programmieren zu lernen sondern es geht urn Forth an sich. Es han¬ 
delt sich urn eine negative Lernkurve wo man sich all jene Fahigkeiten 
abgewohnt auf die es ankommt urn Erfolg zu haben. Es ist nicht uber- 
trieben C-Compiler fur Microcontroller als gut und Forth ais bose zu 
bezeichnen. Das eine strebt einen aktiven Umgang mit Computern an, 
das andere fordert Aberglauben und Desinformation. 

6.3 Ein C to Brainfuck Compiler 

Was Forth ist wurde bereits angedeutet, ein Problem was einer Lo- 
sung bedarf. Forth ist die Frage, ein C-Compiler die Antwort. Genauer 
gesagt geht es darum, wie man C welche die wichtigste Programmier- 
sprache ist, auf Architekturen auszufOhren die als c-unfriendly bekan¬ 
nt sind. Dabei ist Brainfuck ein idealer Kandidat dafur. Es gilt als noch 
unfreundlicher zu C als Forth, es enthalt nochnichtmal einen Stack. 
Und oh Wunder, es gibt tatsachlich einen C to Brainfuck Compiler 13 
Dieser unterteilt das Band zunachst einmal in Bereiche wie Stack, 
Pleap, und Marker. Urn darauf dann Code auszufuhren. 

Es gibt noch weitere Projekte dieser Art, als Motivation geben die 
Autoren uberlicherweise “spaB an der Sache” an, also das Beschafti¬ 
gen mit sinnlosen Dingen zum Zeitvertreib. Eines dieser C to brainfuck 
Projekt lautet treffenderweise Fuckbrainfuck, was wohl andeutet, dass 

13 https://github.com/benjojo/c2bf 
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man sich von der kryptischen Brainfuck Sprache nicht einschuchtern 
lasst und sie im Griff hat aber nicht umgekehrt. Mit “im Griff haben” 
ist gemeint, dass man nachdem der Compiler auf das Ziel einmal 
eingestellt ist, man dann Pacman in Brainfuck spielen kann und im Ex- 
tremfall sogar ein Linux darauf laufen lassen kann. Also die Sprache 
Brainfuck instrumentialisiert fur konkrete Anwendungen. 

Anders ausgedruckt ist die Gemeinsamkeit von Brainfuck und Forth 
dass sie auf langjahrige C-Programmierer provokativ wirkt und man 
sich herausgefordert fuhlt. Ein C-Compiler fOr diese esoterische Plat- 
tform ist der Beweis, dass man der Herausforderung gewachsen ist. 
Das man es also fertig bringt auch auf sehr abseitigen Systemen C 
laufen zu lassen. 

6.4 Esoterische Programmiersprachen 

Unter der URL Esolang 14 findet sich eine Auflistung von esoter- 
ischen Programmiersprachen. Der Begriff ist relativ jung und bezeich- 
net Sprachen die anders sind als C. Aufgefuhrt werden neben Brain¬ 
fuck auch Game of Life auch Intercal und Forth. Forth wird nicht direkt 
als esoterisch bezeichnet kann aber mit dieser Kategorie aufgezahlt 
werden. Die Gemeinsamkeit von Forth und Brainfuck ist, dass es fur 
beide Sprache Bedarf nach einem C-Compiler in diese Sprache gibt. 
Wobei der Bedarf bei Forth noch hoher ist, gewissermaBen befindet 
sich Forth in einer Schonzone weil viele behaupten es ware eine nor- 
male Programmiersprache wahrend C esoterisch sei. Aber diese An- 
sicht ist standard, auch Programmierer die sich mit Brainfuck vertraut 
machen glauben danach dass die Welt auBerhalb irgendwie merk- 
wiirdig sei. Dementsprechend als Sakrileg wird es empfunden wenn 
Compiler existieren die in diese Sprache ubersetzen konnen weil das 
deutlich macht welche Sprache machtiger ist. 

Das interessante an den Esoterischen Programmiersprachen ist, 
dass es sehr einfach ist, sich eine neue auszudenken und dafur einen 
Interpreter zu schreiben, es aber ungleich komplexer ist einen ein 
vorhandenes C-Programm in diese Sprache zu ubersetzen. Auch der 
C to Brainfuck Compiler gilt zurecht als Meisterleistung, nicht jeder ist 
dieser Aufgabe gewachsen. Es bedeutet buchstablich, die Kontrolle 
uber die esoterische Sprache zu erlangen, also deutlich zu machen 
wer die Deutungshoheit besitzt und wer nicht. 

Urn die Bedeutung etwas zu erlautern kann man sich Game of 
life anschauen, eine Programmiersprache die ebenfalls nicht kompat- 
ibel ist zu C. Viele Jahre gait die Sprache als uneinnehmbare Fes- 
tung, es war bekannt wer sie erfunden hat aber es war unklar wie 
ein C-to-Gameoflive Compiler ausseehen muss. In 2002 wurde unter 
der Bezeichnung “Life Universal Computer” ein derartiger Compiler 
vorgestellt. Nicht direkt von C ausgehend sondern von einer vere- 
infachten Sprachsyntax aber immerhin. GewissermaBen ist das die 
erste Schneise in das Dickicht. Mit weiteren Anstrenungen kann man 
darauf aufbauend einen echten C-to-game-of-live Konverter schreiben 
urn dann Linux auf einer Game-of-Life Installation laufen zu lassen. 
Wiedereinmal geht es darum, sich nicht von Esoterischen Program¬ 
miersprachen einschuchtern zu lassen sondern die C-Weltsicht auf 
alles zu ubertragen was halbwegs nach Computer aussieht. 

Was bedeutet es genau eine UTM fur Game-of-Live zu schreiben.? 
Eigentlich dasselbe als wenn man einen C-to-brainfuck Compiler baut. 
Man unterteilt das Band erstmal so wie es ein C-Compiler gerne hat, 
also schon mit Stack, Pleap und Markern urn dann anschlieBend be- 
liebige C-Programme darauf lassen zu lassen. Es gibt auf Youtube ein 
Video wo man sieht wie in Game-of-Live der Stack anwachst. Das be¬ 
deutet, dass man ein wichtiges Bauelement geschaffen hat. Genauer 
gesagt dient eni kontrollierbarerer Stack dazu den C-Compiler in Be- 
trieb zu nehmen. Also am Ende ein normales C-Programm auf diesem 
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Stack laufen zu lassen. Oder es etwas umgangssprachlicher zu for- 
mulieren: sich uber Game of Live zu erheben und es als Esoterische 
Programmiersprache zu definieren die man selbstverstandlich pro- 
grammieren kann in C. 

Game of Life to UTM Schauen wir uns etwas genauer an, was laut 
dem Esolang Wiki im Jahr 2010 entwickelte wurde. Im Grunde wurde 
ein altes Ratsel geknackt und zwar die Frage wie man einen Compiler 
entwickelt der ein C-Programm fur den Game-of-life Automaten bereit- 
stellt. Sehr bescheiden hat der Autor dieses Programms dann nur den 
absolut notigsten Teil veroffentlicht weil er wusste dass es ausreicht. 
Genauer gesagt wurde nicht der komplette C-to-GameofLife compiler 
publiziert, sondern nur der Teil urn eine UTM Notation nach Game- 
oflife zu transformieren. UTM selber ist ebenfalls eine Esoterische 
Programmiersprache aber eine die etwas verbreiteter ist als Game of 
live. Will man ein C-Programm in einer Game-of-life Simulation aus- 
fuhren muss man folgende Pipeline anwenden: 

C Sourcecode -> Brainfuck -> UTM -> Game of life 

Das ist schon alles. Fur alle Schritte in der Pipeline gibt es Software. 
Im Schritt 1 wird das C Programm fur Brainfuck aufbereitet, das heiBt 
auf dem Band wird exakt dasselbe ausgefuhrt was auch das C Pro¬ 
gramm macht, und das wird dann als Input fur den nachsten Compiler 
verwendet und die UTM Machine wird dann am Ende in Game-of-life 
als Stack und Pleap simuliert. 

Anders formuliert eine esoterische Programmiersprache wie Game 
of life ist keine Gegenposition zur Programmiersprache C sondern 
es ist ein ausgedachtes Ratsel. Die Intelliektuelle Plerausforderung 
besteht darin einen C-to-Gameof-life Compiler zu schreiben. Also 
diese abseitige Programmiersprache zuganglich zu machen, sie also 
in den Griff zu bekommen. 

Definition von Forth Mit diesem Plintergrundwissen uber den 
Game-of-Life Automaten lasst sich eine Definition aufstellen was Forth 
eigentlich ist. Forth ist eine hohere esoterische Programmiersprache. 
Genauer gesagt ist es ein Ratsel wie Brainfuck bei dem die Losung 
darin besteht einen C-to-Forth Compiler zu entwickeln. So bekommt 
man die Sprache in den Griff. 

Selbstverstandlich kann man auch Desinformation betreiben und 
behaupten, dass Forth die echte Programmiersprache ware und alles 
andere nur Fake sei. Logischerweise kann man in Forth einen Inter¬ 
preter fur C schreiben Oder versuchen Forth Programme nach C zu 
konvertieren. Nur, diese Desinformation kann man fur die anderen es¬ 
oterischen Programmiersprachen genauso einsetzen. Ja es ist sogar 
moglich, die Brainfuck Sprache in Plardware nachzubauen. 

Anders formuliert, ich glaube das Chuck Moore so eine Art von 
Scherzbold war, der eine esoterische Programmiersprache erfunden 
hat und darauf gewartet hat, dass jemand einen C Compiler dafur en¬ 
twickelt. Und weil das nicht passierte hat er es immer weiter getrieben 
und CPUs fur Forth gebaut die ohne C-Compiler komplett nutzlos 
sind, sondern wiederum als Ratsel gedacht sind, damit sich die C- 
Community mit einem Compiler mehr anstrengt. 

Nochmal Game of Life Schauen wir uns mal an, was passierr ist 
nachdem eine UTM Machine fur Game of Life veroffentlicht wurde. Im 
Grunde hat sich dadurch alles verandert. Es macht keinen Sinn mehr 
direkt in der Game-of-life Syntax sich irgendwelche Patterns auszu¬ 
denken also Muster die die Bilder auf den Screen malen oder ahn- 
liches. Bis man sich solche Patterns uberlegt hat, vergehen Wochen. 
Stattdessen kann man einfach das gewunschte Muster in der UTM 
Syntax vorgeben und daruber dann sehr okonomisch Programme 
ausfuhren. Und zwar beliebige Programme die sich leicht erstellen 
lassen und im Extremfall sogar simpler C-Code sind. 
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Ungefahr das gleiche passiert auch mit Forth. Wenn es irgendwann 
gute Compiler fur diese Sprache gibt, wird es sinnlos direkt in Forth zu 
programmieren. Minimal Instruction Set Computer sind keine Antwort 
sondern sie sind das Ftatsel. Die Flerausforderung lautet auf diesen 
Systemen C-Code laufen zu lassen. 

6.5 Forth ist eine Toy-language 

Als Toy Language versteht Wikipedia Programmiersprachen die sich 
nicht fur den Produktiveinsatz eignen. Sie sind vergleichbar mit 
Domain-specific languages und esoterischen Programmiersprachen. 
Forth erfullt exakt diese Defintion. Es ist zunachst einmal eine es- 
oterische Programmiersprache (es gibt nur wenig Code in Forth) 
mit der sich dann demoan-specific Languages erstellen lassen. DSL 
wiederum sind ebenfalls ais Toylanguage zu klassifizieren weil sich 
damit keine echten Probleme lassen. 

Als weitere Eigenschaft von Toylanguages bezeichnet Wikipedia 
das Fehlen eines Bootstrapping Prozesses, das man also nicht ein- 
fach so einen C-Compiler dorthin portieren kann urn dann ein Be- 
triebssystem zu programmieren sondern dass die Eigenschaften der 
Sprache diesen Ansatz erschweren oder sogar unmoglich machen. 

Das genaue Gegenteil einer Toylanguage ist C. C wird verwendet 
urn unbekannte / esoterische Architekturen mit Software auszustat- 
ten. Mit C werden Programme geschrieben die dann sogar in der 
Brainfuck Sprache ausgefuhrt werden. Insofern ist es logisch Forth 
ebenfalls als Problem zu bezeichnen. 

Toylangues zeichnen sich dadurch aus dass wesentliche Elemente 
von C fehlen: Also Arrays, Records und Pointer, all diese Kriterien 
erfullt Forth, es ist eine Sprache der etwas fehlt. 

Manchmal wird versucht den Begriff Toylanguage in Frage zu 
stellen. Das Argument lautet, dass alle Programmersprachen gleich- 
berechtigt wahren und Forth wie auch Game of live eine ganz nor- 
male Programmiersprache seien und jeder der was anderes sagt 
das beweisen musste. Kein Problem hier ist er: Eine Turing-machtige 
Maschine ist in der Lage ein Programm auszufuhren. Unbestritten 
sind Game of Life und Forth turing-machtig. Die Turing-Machine ist 
jedoch nur die Grundlage fur die man Programme schreiben muss 
urn damit etwas sinnvolles anzufangen. Unterlasst man das Program¬ 
mieren kann man allenfalls Zufallsprogramme ausfuhren. Ob eine Pro¬ 
grammiersprache fur die Praxis taugt, also nicht nur eine Toylanguage 
ist hat damit zu tun, wieviel Geld es kostet dafur ein Programm zu 
erstellen. Bei Plochsprachen wie C ist es relativ preiswert, deshalb 
gibt es auch so viele C-Libraries. Bei anderen Sprachen wie Forth 
ist es hingegen teurer. Der Begriff Toylanguage ist also keiner aus 
der theoretischen Informatik sondern ist gesellschaftlich definiert. Al¬ 
so weiche Funktion Computer und dazugehorige Software haben und 
wie dessen Weiterentwicklung funktioniert. 

6.6 Soziale Implikationen von Stackmachinen 

Es gibt eine Reihe von Projekten bei denen Stackmachinen im Mit- 
telmpunkt stehen. Zu nenenn ist einmal die Forth Community rund 
urn Chuck Moore, aber auch einige Dozenten an den Universitaten 
stellen in ihren Vorlesungen dezidierte Stackcomputer vor. Im letzten 
Paper von Deepmind wurde eine neural Stackmachine implementiert 
und die Programmiersprache Factor wird ebenfalls haufiger erwahnt. 
Wie soil man derlei Projekte einschatzen? Zunachst einmal auf einer 
sozialen Ebene. Ohne etwas wesentliches zu verpassen kann man 
in derlei Vorlesungen anfangen mit seinem Nachbarn ein Gesprach 
uber das Wetter anfangen. Und das Deepmind paper uber die Neural 
Stackmachine kann man ebenfalls in den ReiRwolf schieben. 

Ublicherweise machen die Vertreter von Stackcomputern folgenden 
Fehler. Sie erfinden zwar eine Rechnerarchitektur mitsamt Machinen 


Instruction vergessen jedoch einen passenden C-Compiler beizule- 
gen. Das Factor Projekt zeichnet sich dadurch aus, dass eben kein 
C-to-factor Compiler vorhanden ist, gleiches gilt fur Forth CPUs und 
fur die Deepmind Neural Stackmachine. Wenn es jedoch keine C- 
Compiler in diese Architektur gibt bedeutet es, dass es sich urn ein 
Toylanguage handelt. Man kann das entweder als wertlos bezeich¬ 
nen oder wenn man etwas mehr Ehrgeiz entwickelt der Gegenseite 
einmal zeigen was richtige Informatik ist. Dazu muss man einen C- 
Compiler in diese obskure Sprache programmiren. Also einen C-to- 
Neuralstackmachine, so dass man die esoterische Architektur ganz 
normal in C programmieren kann. 

Warum es fur die Deepmind Neural TuringMachine keinen C Com¬ 
piler gibt ist simpel. Es ist einfacher sich ein Problem auszudenken als 
es zu losen. Und man selber muss das nicht unbedingt tun, weil dann 
garantiert der nachste ankommt der ein leicht andere Stackmachine 
vorstellt wiederum ohne C-Compiler dafur. Und dann wiederholt sich 
das Drama: ohne C-Compiler kann man kein Betriebssystem auf die 
Plattform portieren und ohne Linux kann man kein Pacman spielen. 

Das Problem sind nicht die Stackmachinen sondern das Problem 
ist, dass ist das soziale Machtgefalle. Das also die eine Seite es lustig 
findet sich kunstliche Probleme auszudenken und dann in diesen 
Sinnsysteme andere Leute dahingehend zu testen ob sie die Fra- 
gen richtig beantworten konnen. Ginge es in den Vorlesungen an den 
Universitaten wirklich urns Programmieren und CPUs dann wurden 
als Modellcomputer richtige CPUs behandelt werden fur die es bere- 
its C-Compiler gibt. Wo man also standardmaRig ein Betriebssystem 
und unendlich viel Software drauf laufen lassen kann. Es ist sinnlos 
sich Problem auszudenken wo keine sind. Man kann sich hunderte 
von Programmiersprachen und tauusende von Rechnerarchitekturen 
uberlegen die compiler unfriendly sind. Das ganze ist Schwarze Pad- 
agogik in Reinstform. Es dient dazu eine Negativspirale aufzubauen. 

Eine Neural Stack Machine [7] zu verstehen ist simpel wenn man 
den Nontext kennt in dem sie entstanden ist. Wichtigstes Merkmal des 
ganzen ist es, dass sich die Firma Deepmind einen Scherz erlaubt und 
eine esoterische Programmiersprache uberlegt hat, fur die es aktuell 
noch keine C-Compiler gibt urn daruber ein Sinnsystem zu konstru- 
ieren indem sie die einzigen sind die wissen wie es funktioniert. Das 
Paper ist weniger die Antwort auf ein Problem der Informatik, sondern 
ist ahnlich wie Brainfuck oder Game of Life ein Programmierratsel. Be- 
hauptet wird, dass es sich urn ein neuartiges Rechenmodell handelt 
in Wahrheit fehlt einfach nur ein C-Compiler das ist alles. Die Mas- 
chine ist genauso turing-machtig wie alle anderen Computer, nur ist 
es eben anstrengend fur eine Stackmachine zu programmieren. Den 
Fehler den Deepmind macht ist, dass sie nicht zugeben, eine Toylan¬ 
guage erfunden zu haben und das es ein Ratsel sein soil, sondern 
sie behaupten es ware echte Informatik. In Wahrheit ist die Neuronale 
Stackmachine kompletter Unsinn. Man kann mit einem normalen Ras- 
berry PI die selben Berechnungen sehr viel preiswerter ausfuhren. 

Es handelt sich urn eine sehr hinterlistige Form von Unsinn weil 
es fur sich betrachtet zunachst Logisch klingt. So als ob da jemand 
wirklich den Dingen auf den Grund geht und andere einladt ihm 
dabei zu folgen. Tatsachlich ist das ganze kein Informatik Projekt als 
vielmehr ein Padagogik Projekt. Wer es sich leisten kann, eine Stack- 
machine vorzustellen und andere in die Rolle drangt das verstehen zu 
mussen der besitzt soziale Macht. Er kann entscheiden was an den 
Plochschulen gelehrt wird. 

Die Alternative zu diesem Quatschpaper von Deepmind beste- 
ht darin, zur Abwechslung mal eine “c-compiler friendly” Architektur 
vorzustellen. Also einen Computer wofur es bereits einen C-Compiler 
gibt, auf dem ein Standardbetriebssystem lauft und wo man nichts 
verstehen muss sondern weitere Programme dafur schreibt. 

Angenommen es geht wirklich darum, die Informatik voranzubrin- 
gen. Welchen Sinn macht da ein Computer auf dem ein C-Compiler 
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nicht lauft, bzw. erst noch muhsam einer programmiert werden muss? 
Und wenn es nicht gelingt, hat man ein System ohne Software, also 
genau das, was nicht das Ziel ist. Es sei denn man will die Informatik 
nciht voranbringen sondern empfindet sie als Bedrohung. Dann hat 
man ein Interesse an Inkompatibilitat, dann ist man stolz darauf dass 
C-Programme nicht ausfuhrbar sind. 

6.7 C Compiler 

Nachdem erlautert wurde, warum Forth, Brainfuck und Game of 
Life ungeeignet sind soil einmal die Programmiersprache C etwas 
genauer untersucht werden. Gibt es irgendwas was falsch ist mit 
C? Wohl kaum, C ist die wichtigste Programmiersprache. Wenn man 
sie auf einer c-friendly Hardware ausfuhrt erhalt man eine Program- 
mierumgebung mit der man weitere Dinge machen kann. Aber warum 
hat C dann so schlechtes Image? Warum wird an den Universitaten 
alles mogliche erzahlt nur nicht das C super ist? 

Schauen wir uns dochnochmal die Welt auBerhalb von C an. 
Nehmen wir mal an, man sich eine Stackmachine uberlegt auf der 
man Forth zum Laufen bringt. Im Grunde hat man alles getan urn ein 
Bootstrapping zu verhindern. Genauer gesagt hat man sich den Ast 
abgesagt auf dem man sitzt. Oblicherweise sind Forth Programmierer 
nicht in der Lage in Forth einen C-Compiler zu programmieren der auf 
ihrem System lauft urn damit weiteren Code zu ubersetzen der schon 
da ist. Und das bedeutet nichts anderes, als dass die neuentwickelte 
Plattform ihnen ganz allein gehort. Sie konnen sich Aufgaben uber- 
legen von denen die Antwort bekannt ist und die unter C keinen Sinn 
machen. Ein Primzahlprogramm in C zu schreiben ist simpel, uber 
Copy&Paste hat man das in weniger als 10 Minuten erledigt. Bei Forth 
hingegen ist es schwerer. Erstens lauft der C-Code nicht und will man 
es in Forth nachprogrammieren dauert es. 

Haufig wird argumentiert dass eine Stackmachine mitsamt Forth 
das Denken in ungewohnten Bahnen trainieren wurde. Das Gegen- 
teil ist der Fall. Es ist nichts anderes als Latainunterricht der mit einer 
Prugelstrafe angereichert wurde. Nicht urn die Schuler geht es, son¬ 
dern urn die Bedurfnisse des Lehrkorpers. Forth ist eine sehr effektive 
Methode wie man Informatikstudenten zu Versagern erklaren kann. 
Es ist ein Sinnsystem was sie nicht durchschauen und wo der Lehrer 
der einzige ist, der zwischen Rlchtig und Falsch unterscheidet. Forth 
ist eine autoritare Unterrichtsmethode welche uber Strafe funktion- 
iert. Nicht Erkenntnis ist das Ziel sondern Gehorsam. Forth hat die 
Aufgabe, eine Gegenoffentlichkeit zu bauen, wo man mit seinen C- 
Kenntnissen nichts anfangen kann. Forth kann man nicht verstehen 
Oder lernen sondern Forth kann man nur hassen. Dieses Gefuhl ist 
normal und es ist so gewollt. Es soil einschuchtern, gefugig machen 
und Abhangigkeit herstellen. 

Die einzig richtig Antwort auf Forth besteht darin, sich daruber lustig 
zu machen. Forth mag es nicht, wenn man es also Toylanguage beze- 
ichnet, Forth hat ein Problem infrage gestelit zu werden. Forth will 
nicht verspottet werden. 

Jokes uber Forth finden sich hier 15 

6.8 C-friendly Compiler 

Urn auf die Besonderheiten von Forth einzugehen ist es wichtig 
zunachst einmal sprachlich zu beschreiben, woran die Welt auBerhalb 
der Forth Community interessiert ist. Neue CPU die auf den Markt 
kommen werden nach einer MaBzahl namens “c-friendly” eingestuft. 
Es handelt sich dabei urn Bedurfnisse von G-Compilern wie GCC. 
Oblicherweise benotigen solche Compiler CISC CPUs mit vielen Reg- 
istern. Dafur konnen sie guten Maschinencode erzeugen. Wenn eine 
CPU diese Kriterien nicht erfOllt wie z.B. die PIC CPU und erst 
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recht die Stackmaschinen von Chuck Moore, gelten diese CPU als c- 
unfreundlich und werden als schwer zu programmieren bezeichnet. Es 
gelingt nicht Oder nur unter groBem Aufwand dorthin einen C-Compiler 
zu portieren. Und ohne C-Compiler kann man auch keine Betriebssys- 
teme auf diese Plattformen bringen. Aus Sicht der Ingineure muss 
man dann uber Alternativen nachdenken. Vielleicht etwas konkreter: 

Ein Ingineur erhalt bei sich auf dem Schreibtisch die neue GA144 
CPU. Er schaut in das Datenblatt und erkennt, dass diese CPU nicht 
C-friendly ist. Sie hat keine Register und noch einige weitere Beson¬ 
derheiten wodurch es nicht moglich ist, dorthin einen C-Compiler 
zu portieren. Wenn er dennoch fur diese CPU Software entwickeln 
mochte Oder muss dann sind Alternative Ansatze notig. Und die sind 
teuer. Konkret geht es darum, fur die GA144 Software zu entwickeln 
wenn kein C-Compiler zur Verfugung steht. Der Ingineur konnte jetzt 
anfangen, einen eigenen C-Compiler zu programmieren der speziell 
auf Stackmachinen fokussiert ist, Oder er konnte manuell Forth Code 
programmieren. Beides ist grundsatzlich moglich aber nicht so einfach 
als ware es ein c-freundlicher Prozessor. 

Die Hersteller neuer CPUs haben Oblicherweise ein Interesse an 
hohen Absatzzahlen. Also entwickeln sie den Instruction Set so wie es 
angenehm ist fur C-Compiler. Dies wird als x86 Standard bezeichnet. 
Kommen wir jetzt zu den Forth CPUs. Diese sind nicht nach dieser 
MaBgabe entwickelt worden. Es gibt zwar die CPU, doch fehlt dazu 
noch die passende Software. Die wichtigste Eigenschaft von Stack¬ 
machinen ist, dass sie Probleme erzeugen. Das heiBt, sie sind dsa 
genaue Gegenteil von c-friendly, eben wie ein Fixed Gear Bike. 

Wie man fur Stackmachinen Software entwickelt ist unklar. Mit 
einem C-Compiler jedenfalls nicht. Oblicherweise werden Stackma¬ 
chinen in Forth programmiert und zwar manuell. Das heiBt, man 
schreibt das Programm from scratch und zwar in Standard-Forth. 
Weil das naturlich seine Zeit dauert, gibt es nur wenige Forth Pro¬ 
gramme. Dadurch, dass Stackmachinen c-unfreundlich sind, hat sich 
urn Forth eine Aura des elitaren gebildet. Es ist kein allerweltsprozes- 
sor, manche sagen dass Stackmachinen des Teufels sind. Also bose. 


7 Minimalismus 

7.1 Was ist Minimalismus? 

Die Forth Community gibt sich der Illusion hin, dass ihre Program¬ 
miersprache minimalistich ware. Grund fur die Behauptung ist der 
Codeumfang eines Forth Systems was mit 4 kb im Vergleich zu C 
sehr kompakt ist. Auch ein Forth Programm was ausgefuhrt wird 
ist selten groBer als 2 kb. Nicht viel anders versuchen auch die C- 
Programmierer im Ideal des Minimalismus zu sonnen. Da wird gesagt, 
dass man mit Hilfe der ulibc sehr kompakte Binarys schreiben kann, 
nicht ganz so klein wie in Forth aber mit 10 kb immernoch sehr 
kurz. Auch die C-Programme welche auf Micromouse Microcontroller 
geflasht werden orientieren sich an einem astethischen Minimalismus 
in der Art dass sie auf maximale Effizienz getrimmt wurden. Aber ist 
Forth und C schon echter Minimalismus? 

Im Kern wird als Minimalismus ein selbstgewahltes Bezugssystem 
verstanden. Konkret die Fahigkeit mit einer geringen CodegroBe und 
einem langsamen kleinen Prozessor auszukommen. Das wird gle- 
ichgesetzt mit einem erwunschten Verhalten wodurch die Aufgaben 
uberschaubar werden. Man hat ein sehr abgegrenztes Gebiet auf 
dem man die optimale Losung entwickelt und dafur dann eine Be- 
lohnung erhalt - so die Vorstellung. Leider sind sowohl Forth als auch 
C-Programmnierer einem Trugbild aufgesessen und zwar der Vorstel¬ 
lung dass ein System uberschaubar bleibt, wenn der Hauptspeicher 
weniger als 100 kb betragt. Minimalismus ist nichts schlechtes, son¬ 
dern es kommt auf die Kriterien an ihn zu messen. 
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ich sage, dass Minmalismus darin besteht, einen Rasberry PI Com¬ 
puter zu nutzen der uber 1 GB RAM und 64 GB Flash-Memory ver- 
fugt und auf diesem ein Robot-Control-System auszufuhren was aus 1 
Million Lines of Code besteht. Aus Sicht der heutigen Microcontroller- 
Community mit ihrer Bare-Metal-ldeologie stellt das ein schlimmes 
Sakrileg dar, weil nach ihrem Denksystem es sich dabei urn aufge- 
blahte Hardware und Software handelt. Doch im Grunde sind Sys- 
teme mit 1 GB Ram die Inkarnation von Minimalismus, nur die Metho- 
den urn Komplexitat zu reduzieren sind andere. Will man Programme 
schreiben die aus 1 Million Codezielen bestehen benotigt man selb- 
stverstandlich Methoden urn die Komplexitat zu senken. Wenn man 
diese nicht besitzt entsteht allzuschnell Chaos und es entsteht Bloat¬ 
ware. Eine Moglichkeit besteht darin, wenn man objektorientierte Pro- 
grammiersprachen nutzt, eine weitere sind UML Diagramme. Dortgibt 
es ein Designelement namens Packages, was die Aufgabe hat, viele 
Einzel-Klassen zu einer hoheren Gesamtheit zu vereinen. Wenn man 
sich das entsprechende UML Diagramm ansieht ist es sehr minimal- 
istisch. Man hat 3-4 Packages die genau bundig auf dem Bildschirm 
angeordnet sind, einige wenige Verbindungsfeile und das entspricht 
dann 1 Mio Codezeilen. 

Es ist also keineswegs so, dass groBe Programme und umfan- 
greiche Betriebssysteme automatisch uberladen sind sondern worauf 
es ankommt ist Komplexitat zu managen. Wenn man lediglich ver- 
sucht den Speicherbedarf von Software zu minimieren oder ein C- 
Programm in 32 kb Flash unterzubringen verwendet man den falschen 
Ansatz zur Komplexitatsredukution. Es erinnert ein wenig an Cargo- 
Cult-Science auf diese Weise Probleme Ibsen zu wollen. 

Der wichtigste MaBstab urn Minimalismus zu erkennen ist 
okonomischer Art. Genauer gesagt die Kosten urn ein Projekt 
durchzufuhren. Einmal sind es die Hardwarekosten selber, aber auch 
der Zeitaufwand bis das Ergebnis erzielt wurde. Wenn es gelingt die 
Projektkosten zu senken hat man verstanden was Minimalismus be- 
deutet. Projekte in denen Micocontroller mit C Oder noch extremer mit 
Forth programmiert werden haben die Eigenschaft sehr teuer zu wer- 
den. Damit ist gemeint, dass da ein Team aus 12 Leuten uber Wochen 
irgendwelche Anderungen vornimmt nur damit am Ende der Robot- 
er exakt gar nichts tut weil noch irgendwelche Bugs nicht gefixt wur- 
den. Zwar gibt es auch in diesen Teams eine Vision davon wohin das 
Projekt sich entwickeln soil, aber es ist eine die sich nicht erreichen 
lasst. Es wurde zuviel kosten sie umzusetzen. in Folge dessen laufen 
Anspruch und Realitat auseinander. Vom Selbstverstandnis haben die 
Teammitglieder nach 3 Monaten harter Forth-Programmierung so eine 
Art von Skynet-Betriebssystem fur einen Roboter programmiert, de- 
fakto jedoch fahrt die angeblich so minimalistische Micromouse gar 
nicht in Ziel. 

CodegroBe Wie man in Forth Oder in Assembler einen Computer 
progrmmiert ist einfach. Man schreibt die Routinen die man benotigt 
hin und fertig. Beispielsweise wird die WLAN Karte vom BIOS erkan- 
nt und es braucht nur wenige Codezielen in Forth um die Karte on¬ 
line zu bringen und mit einer Basisstation zu verbinden. Dafur braucht 
man kein eigenes Betriebssystem sondern das geht in 50 Zeilen auch 
so. Ebenfalls vom Bios unterstutzt wird die Grafikkarte. Benotigt man 
einen Pixel auf dem Bildschirm aktiviert man diesen. Im Extremfall 
uber zwei kurze Zeilen. Was also soil der Unsinn mit Linux und darauf 
aufbauenden Systemen? 

Schauen wir uns den Linux Kernel in seiner aktuellen Version an. 
Der Sourcecode des letzten Stable Release benotigt gepackt 98 MB 
auf der Festplatte. Ist das viel oder wenig? Aus Sicht von Forth ist 
das viel. Es handelt sich um Bloatware die keinen Zweck erfullt und 
Ausdruck von Unverstandnis gegenuber der Hardware darstellt. Ein 
wenig realistischer betrachtet sind 98 MB gar nicht mal soviel. Ein 
gutes Buch uber Compilerprogrammierung benotigt als PDF Datei 5 


MB auf der Festplatte. Der Kernel benotigt also nicht mehr Platz als 
20 Bucher aus einer gut sortierten Oreilly Serie uber systemnahe Pro- 
grammierung. Und waren es nicht 98 MB sondern 300 MB ware es im- 
mernoch wenig. Weil das Thema komplex ist und viele Dinge beachtet 
werden mussen. Der Grund warum man dazu Bucher benotigt und es 
als Linux Kernel niederschreibt hat damit zu tun, dass man daruber 
das Wissen zuganglicher macht. Man braucht also eben nicht selbst 
wissen wie man im Bios die Grafikkarte aktiviert sondern der Kernel 
weiB das. Es ist dort notiert als ausfuhrbarer C-Code. Dieses Prinzip 
Wissen in Buchern aufzuschreiben und als Kernel zu formalisieren di- 
ent dazu Komplexitat zu senken. Das heiBt die 98 MB groBe Datei mit 
den Linux Sourcen ist einfacher als das 2 kb groBe Jonesforth. 

Was die Forth Community als erstrebenswert bezeichnet ist der 
Ruckfall in eine mundliche Kultur. Damit ist gemeint, dass das Wis¬ 
sen fiber Betriebssysteme nicht in Buchern niedergeschrieben steht 
und auch nicht als C-libraries maschinenlesbar verfugbar ist, son¬ 
dern es personenzentriert in den Kopfen der Forth Programmierer 
existiert. Im Extremfall lauft das auf die Idee des Sourceless Pro¬ 
gramming hinaus, wo es also keinerlei BGcher gibt und auch keinen 
Sourcecode, sondern man alles im Kopf memoriert und mit wenigen 
Bootstrap-Anweisungen einen Computer hochfahrt. Dieser Ansatz ist 
keineswegs etwas was es nur in der Computerbranche gibt, sondern 
man kann auf diese Weise auch Medizin, Jura und Literatur durch- 
fuhren. Das heiBt, Geschichten werden grundsatzlich nur mundlich 
weitergegeben, Wissen im personlichen Gesprach vermittelt, es gibt 
keine externen Bibliotheken wo man sich frei informationen beschaf- 
fen kann. Es handelt sich dabei um Wissensmonopole die aufrechter- 
halten werden. Derjenige der das Wissen besitzt nimmt eine heraus- 
ragende Stellung in der Gesellschaft ein. Und wird der Medizinmann 
entfuhrt, weiB der komplette Stamm nicht mehr wie man Krankheiten 
heilt, weil es nirgendwo niedergeschrieben steht. 

Ungefahr das ist die Ideologie hinter Forth. Das man also nichts 
aufschreibt und keine Bibliotheken anlegt sondern sich stattdesen 
trifft und daruber sehr limitiert Wissen weitergibt. Die Idee dahinter 
lautet, daruber die Komplexitat zu senken, also die Menge an Wis¬ 
sen zu reduzieren und die Anzahl von Personen zu senken die damit 
in Beruhrung kommen. Wie man das bewertet muss jeder selber 
entscheiden. Fakt ist, dass der Ansatz das Genaue Gegenteii der 
Aufklarung und der Erfindung des Buchdrucks darstellt. Forth kon- 
nte man also als Ruckschritt in eine als positiv empfundene Vergan- 
genheit bezeichnen. Es werden gedruckte Informationen abgelehnt, 
genauso wie formale C-Libraries abgelehnt werden. 

7.2 Ferngesteuerte Roboter 

In einem Aufsatz uber Forth Programmierung war zu lesen, dass das 
kleinst mogliche Forth System aus genau 2 Befehlen besteht. Der Be- 
fehl 1 wartet auf ein Signal von auBen und Befehl 2 schreibt das in 
eine Speicherstelle des Computers. Auf den Micromouse Wettbewerb 
ubertragen bedeutet es, dass man den Microcontroller ausbaut und 
ihn durch eine Fernsteuerung ersetzt. Das kann sogar eine analoge 
Fernsteuerung sein, die nichts macht als entsprechend der Fernbe- 
dienung die Motoren zu aktivieren. Meiner Ansieht eine ausgezeich- 
nete Idee, weil man sich dann den Aufwand mit den MSP430 Micro- 
controllern, der C Programmierung und der Forth Programmnierung 
sparen kann. Das heiBt, man baut aus dem Roboter die komplette 
Logik aus und verwandelt es in einen steuerbaren Aktuator. 

Gleichzeitig wird damit der Weg frei um ernsthaft uber Kunstliche 
Intelligenz nachzugrubeln. Weil nach wie vor die Frage im Raum steht 
welcher Algorithmus die Fernbedienung steuert. Rein technisch kon- 
nte das eine hochgezuchtete Workstation sein, also 16 GB RAM, 
Fedora Betriebssystem, High-End Grafikkarte. Man verzichtet also 
nicht wirklich auf den Part mit dem Computer, sondern spaitet das 
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Problem lediglich auf. In der Micromouse gibt es einen Analogen 
Empfanger der tatsachlich nur aus simplen Schaltkreis besteht und 
auf der Sender-Seite hat man dann einen vollausgestatteten Comput¬ 
er mit alien Extras. Was man nicht mehr hat ist Microcontrollerpro- 
grammierung. Also keine in Assembler geschriebenen Programme, 
auch keine Forth Scripte mehr, sondern stattdessen hat man Java 
Programme die viele Megabyte benotigen wenn man sie starten will. 

Technisch ist das machbar nur verletzt es die ungeschriebenen 
Regeln. Unter einem Micromouse Roboter wird derzeit zwingend ein 
Microcontroller verstanden, also 16-bit Kleincomputer mit 16 kb RAM 
der in C programmiert wird und wo man das Programm auf den Chip 
draufflasht. Es geht also um autonome Roboter, die ihre Computer on¬ 
board mitfuhren. Aus Sicht der Kunstlichen Intelligenz ist das jedoch 
das selbe, als wenn man die Micromouse mit einer Fernsteuerung 
ausstattet. In beiden Fallen benotigt man Software die Entscheidun- 
gen trifft. Vielmehr sind es unterschiedliche Umsetzungen. Ich wage 
mal die These, dass die Variante mit der analogen Fernsteuerung 
die bessere ist. Man kann damit die Micromouse sehr viel kompak- 
ter bauen und hat gleichzeitig auf der Workstation mehr Moglichkeit- 
en groGe Programme zu fahren. Machen wir uns nichts vor, will man 
heutzutage in Python programmieren und will man mit Simulationen 
arbeiten benotigt man viel Rechenleistung. Und nach wie vor sind 
Desktop PC die einzigen Gerate die das leisten. Desktop PCs sind wie 
der Name schon sagt, schwere Gerate die viel Strom verbrauchen. 
Man muss sich also entscheiden. 

Eine Fernsteuerung ist aus zwei Griinden interessant. Erstens, 
kann man sie analog realisieren, also ohne CPU und zweitens kann 
man sie uber einen human-operator steuern. Fragen wir dochmal die 
Handler was sie als Micromouse verkaufen. Einmal gibt es klassische 
Robotik-Handler welche darunter einen Roboter verstehen. Also eine 
Platine mit ATMega32 Microcontroller was 100 US$ kostet, mit dem 
entsprechenden Programmiergerat kommt man auf 120 US$. Es gibt 
jedoch auch Remote controlled Micromause, das sind keine Roboter 
und werden fur 15 US$ das Stuck verkauft. Diese werden mit einer 
Fernbedienung gesteuert. Sie werden meist als Spielzeug fOr Katzen 
verkauft, wo der Tierbesitzer damit sein Haustier bespasst. Das in- 
teressante ist, dass letztere bei den offiziellen Micromouse Wettbe- 
werben nicht verwendet werden. Es gibt dort keine Scherzbolde die 
mit so einem Teil ins Labyrinth vorrucken, sondern 100% aller Teams 
verwenden Microcontroller-Basierende Roboter. 

Lediglich bei Robocup gibt es eine eigene Liga wo passive FuGball- 
roboter am Start sind. Die werden uber externe Kameras getrackt und 
enthalten keine eigene Logik. 

7.3 Remote Controlled Micromouse 

Heute durchgefuhrte Roboterwettbewerbe sind noch viel zu stark auf 
Elektronik fixiert. Ublicherweise geht es bei Micromouse und anderen 
Challanges darum, 16bit Microcontroller zu programmieren und damit 
Aufgaben zu Ibsen. Die Idee lautet, dass diese Fahigkeiten wichtig 
seien und man so etwas uber Technik iernt. Es gibt jedoch eine Al¬ 
ternative dazu. Und zwar eine die preiswerter ist. Sie besteht darin, 
dass man die rund 150 US$ teuren Microcontroller-Roboter durch 
Remotecontrolled Micromause ersetzt. Diese gibt es fur 15 US$ als 
Elektrospielzeug in der Zoohandlung und haben sogar ein aufgenaht- 
es Fell. Normalerweise werden Remote controled Micromause von 
Katzenbesitzern gekauft, sie enthalten intern gar keinen Microcon¬ 
troller sondern werden analog gesteuert. Im Grunde muss man an 
die Fernbedienung nur einen Arduino anschlieGen und schon kann 
man das Spielzeug mittels Computer steuern. Der Vorteil ist, dass 
man einerseits riesige Programme ausfuhren kann, gleichzeitig aber 
die Elektronik minimalistisch ist. 

Das Problem mit heute durchgefuhrten Micromouse Wettbewer- 


ben ist, dass man sich da schnell verzettelt. Um die ublichen 
Microcontroller-gesteuerten Systeme online zu bekommen muss man 
sich auskennen mit Hardware-Baastelei, Assemblerprogrammierung, 
C-Programmierung und Kleinstbetriebssystemen wie sie auf Micro- 
controllern verwendet werden. Ohne dieses Wissen wird man scheit- 
ern. Nur, das Wissen ist uberflussig, man braucht es nur, wenn ein 
echter Microcontroller verwendet wird. Es erhoht die Komplexitat un- 
notig. Zeit die dafur aufgwendet wird, fehlt bei der eigentlichen Pro- 
grammierung. Besser ist es, auf Microcontroller zu verzichten und sich 
stattdessen mit Softwareentwicklung zu beschaftigen. Die so erstell- 
ten Micromause sind sehr viel effiizienter. 

7.4 Anziehungskraft von Forth 

Warum auch heute noch Forth bei vielen beliebt ist hat mit der ver- 
meintlichen Einfachheit von Forth zu tun. Angesichts von immer kom- 
pler werdenen CPUs mit Milliarden von Transistoren, und angesichts 
von undurchschaubaren GUI Oberflachen wunschen sich viele ein 
einfaches minimalistisches System zuruck was ihnen einen direkten 
Zugang zur Machine ermoglicht. Viele sehen in Forth ein solches Sys¬ 
tem, was nicht nur Betriebssysteme sondern auch Registermaschinen 
uberflussig macht. Die Einfachheit von Forth wird an zwei Parametern 
gemessen, einmal dass eine Forth Programmierumgebung inkl. Be- 
triebssystem nicht mehr als 5 kb benotigt und das eine Forth CPU 
nicht mehr als 1000 Transistoren benotigt. 

Aber sind solche Systeme wirklich minimalistisch? Bekanntlich 
kann man in einem Hobbyprojekt auch eine minmale CPU zusammen- 
bauen aus wenigen Transistoren die mit einer Assemblerartigen Pro- 
grammiersprache angesprochen wird. Aber minimalistisch ist so eine 
Architektur ganz sicher nicht. Ganz im Gegenteil versucht man solche 
Computer zu verkaufen will sie niemand haben. Sie sind zu teuer. 
Der Kaufer miisste sich nicht nur mit der Verdrahtung der CPU au- 
seinandersetzen sondern er musste auch Assemblersprache lernen. 
Viel einfacher ist es fur ihn, wenn er sich einfach einen Standard-PC 
kauft dort Windows draufspielt und fertig. Das Problem besteht darin 
wie man Einfachheit misst. Allein der Codeumfang und die benotigte 
Zahl an Transistoren ist kein guter MaGstab, sondern man muss die 
Projektkomplexitat anhand von okonomischer Faktoren bestimmen. 
Damit ist gemeint, dass eine CPU mit 10 Milliarden Transistoren ein¬ 
fach er ist als eine mit 1000 Transistoren. 

Schauen wir uns ein Beispiel aus der Softwareentwicklung an. 
Einige trauern den fruhen Zeiten von Linux hinterher wo der komplette 
Kernel auf einer 3,5 Zoll Diskette Platz fand. Wollte man versuchen mit 
diesem Kernel ein heutiges System zu booten wird man sehen, dass 
es technisch gehen mag, aber dass es sehr teuer wird. Weil man sehr 
viel lesen muss, Erweiterungen programmieren und selbst dann wird 
die Leistung niedriger sein, als wenn man einen aktuellen Kernel be- 
muht. Rein nominell sind heutige Linux Kernel sehr viel umfangreich- 
er als ihre Pendants in den 1994'er, trotzdem wurde dadurch effektiv 
Komplexitat reduziert. 

Die Zukunft liegt darin, dass nominell die Systeme an Umfang zule- 
gen, aber qualitttiv umso uberschaubarer werden. 

7.5 Neoludditen traumen von Forth 

Die technische Weiterentwicklung aufzuhalten ist simpel: und zwar 
muss man einfach in die Vergangenheit blicken und jene Dinge 
hochhalten, die damals relevant waren. Wenn man Computer aus 
den 1980’er Jahren verwendet die moglichst wenig Hauptspeicher 
und noch gar kein Betriebssystem hatten ist das der beste Schutz 
gegen Kunstliche Intelligenz. Es gibt auf Youtube viele Bastelprojek- 
te wo Leute die fruher auf C-64 Treffen und Forth-User-Treffen aktiv 
waren jetzt damit anfangen ihr Wissen in die Gegenwart zu ubertra- 
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gen. Das bedeutet konkret, dass alles abgelehnt wird was modern und 
zukunftsorientiert ist und stattdessen man sich aus eigenen Chips und 
selbst erstellter Software einen Roboter baut. Also schon mit Micro¬ 
controller, selbst programmierten Betriebssystem und am besten noch 
selbst-geatzten Leiterbahnen. Damit wird ein ganz besonderer Retro- 
Style erzeugt wo man im Jahr 2017 jene Technologie kopiert die in 
den 1980’er erfunden wurde und das mit heutigem Wissen aufwertet. 

Dieser Retrostyle hat mehrere Grunde. Einmal versuchen die 
Bastler daruber Komplexitat zu senken. So nach dem Motto: wenn 
der RAM des PC nur 30 kb groB ist, ist es leichter den Computer zu 
verstehen. Zweitens wird das Fachwissen aus der Vergangenheit als 
wertvoll erachtet und zu guter letzt ist es ausgeschlossen, dass einer 
der so programmierten Roboter echte Intelligenz zeigt. Die wichtigste 
Eigenschaft von Retro im aligemeinen und Forth im Besonderen ist, 
dass die Projektkosten damit in die Hohe gehen. Wer nochmal sein 
eigenes Betreibssytem und seinen eigenen Compiler from scratch en- 
twickelt der kann sich jahrelang damit beschaftigen ohne jemals etwas 
konkretes zu realisieren. Man bastelt so vor sich hin und schafft sich 
Raume die man leicht uberblicken kann. Das hier ist der Befehl urn 
etwas auf den Stack zu pushen, dass hier ist der 9v Servomotor und 
das da, ist mein selbsterstellter Editor in 50 Lines of Code. Alles Klar, 
die Welt ist unter Kontrolle. 

Dazu gibt es naturlich eine Gegenbewegung. Diese ist nicht auf 
konkrete Computer oder konkrete Programmiersprachen fixiert son- 
dern versucht die Projektkosten zu senken. im Zentrum steht der Wun- 
sch einen Roboter zu entwickeln der mbglichst in einem Wettbewerb 
gewinnt und zwar mit moglichst wenig Aufwand. Die konkrete Tech¬ 
nologie ergibt sich aus dieser Pramisse. Sie lautet, dass man vorhan- 
dene COTS Systeme nutzt, also Standard-Notebook, Standard-Linux 
und das man den Plardwareteil des Roboters moglichst reduziert. Das 
heiBt, man verwendet ein RC Car, modifiziert dort den RC Transmitter 
urn ihn via Arduino anzusteuern und installiert im Raum mehrere Kam- 
eras urn eine Virtual Realiy Umgebung herzustellen. Dann wird Uni- 
ty3D genutzt urn darin Scripte zu starten die den Roboter ins Ziel brin- 
gen. Das ware die Lowcost Version zur Robotersteuerung. Mit Forth 
oder Plardwarebastelei hat es nichts mehr zu tun, sondern hier geht 
es urn richtige Robotik. 

8 Challanges 

8.1 Der Micromouse Wettbewerb 

Nach meiner Recherche ist der Micromouse Wettbewerb genau ein 
Mittelding zwischen Mainstream Informatik und Forth Community. Er 
ist deshalb Mainstream weil dort C-Programmierer aktiv sind, aber 
aus Sicht von Forth ist es interessant weii einige der Microcontroller 
so kompakt sind, dass nur Forth darauf lauft und sonst gar nichts. Die 
wichtigste Frage ist naturiich wie man bei einem solchen Wettbewerb 
gewinnt, und zwar stellen sich diese Frage sowohl C-Programmierer 
als auch Forth Leute gleichermaBen. Ublicherweise lautet die Antwort 
darauf, dass es auf den richtigen Algorithmus ankame, also ein 
Floodfill-Algorithmus, ein Mapping Algoirthmus oder ein Verfahren urn 
die Sensoren auszulesen. Meine Beobachtung ist hingegen, dass die 
Algorithmen fast egal sind, sie sind austauschbar und es ist schw- 
er den besten zu ermitteln. Worum es eher eher geht ist Software- 
Engineering, also wie man mit begrenzter Manpower die Anforderun- 
gen des Wettbewerbes erfullt und wie man vorgeht wenn die Software 
einen Bug enthalt. 

Mit diesem Mindset erkennt man, dass Micromouse eben kein C- 
Programmierwettbewerb und erst recht kein Forth Contest ist. Der 
Grund warum sich einige dennoch darauf fokussieren ist weil sie es 
nicht anders gelernt haben. Sie glauben, dass man sich intensiver 
mit der Plardware beschaftigen musste und dass man stundenlang 


mit dem Lotkolben an der Jtag Schnittstelle herumdoktern musste. 
Andere glaube, es ginge darum den Compiler optimal auszunutzen 
und jedes Byte zu verwenden was der RAM hergibt. Dabei ist die 
eigentliche Stelle worauf man seine Energie konzentrieren sollte eher 
ungewohnlich fur diesen Wettbewerb: es ist naturlich die Software. 

Will man Micromouse richtig spielen, so wird man dazu objekto- 
rientierte Programmiersprachen, Issue-Tracker und UML Diagramme 
benotigen. Gerade weil es sich urn eine Embedded Competition han- 
delt muss man da so vorgehen als wurde man fur ein Unternehmen 
ein Java-Framework entwickeln. Die benotigten Fahigkeiten urn auf 
Platz 1 zu kommen sind angesiedelt zwischen Projektmanagement, 
Wissenschaftlicher Quellenrecherche und Java Programmierung. Mit 
diesem Mindset kann man dann ganz am Ende und als nebensach- 
lichste Aufgabe von allem den fertigen Assembler Code auf den Micro¬ 
controller draufspielen oder alternativ den Forth code programmieren. 
Ich wurde mal schatzen, dass der reine Code urn den Microcontroller 
zu steuern in weniger als 50 kb hineingeht. Entweder hocheffizienter 
Forth-Code oder per C-Compiler assemblierter Plochsprachencode. 
Urn jedoch diese 50 kb zu schreiben muss man vorher dutzende Pro- 
totypen im Simulator getestet haben, man muss Literatur ausgewertet 
haben und man muss mit Java UML Diagramme gezeichnet haben. 
Anders geht es nicht bzw. artet aus in Rumprobieren. 

Schaut man sich einmal erfolgreiche Teilnehmer der Challange 
an, so gibt es da nicht den einen Algorithmus der auf magische 
Weise den Roboter steuert, sondern ublicherweise wurden sehr 
viele Detailfragen in Software geklart. Angefangen von der Einschalt- 
prozedur, das heiBt das nach dem Druck auf den Button das Teil 
wirklich losfahrt, fiber die Wegeplanung, das Navigieren in Kurven, 
spezielle Pleurstiken fur Highspeed Fahren bis hin zur Objekterken- 
nung. Am ehsten kann man diese Verfahren noch unter dem Be- 
griff des Scripting Al zusammenfassen, bzw. subsumption Architek- 
tur. Etwas genauer gesagt geht es darum, die Domane Micromouse 
in Codezeilen zu uberfuhren. Das ist ungefahr das, was die Teams 
dort machen. 

8.2 Projektdenken anstatt Forth Programmierung 

Welche Kernkompetenzen sind erforderlich urn bei der Micromouse 
Challange erfolgreich zu sein? Auf den ersten Blick sieht es danach 
aus, als ob es urn Programmieren eines Microcontrollers ginge. Fol- 
glich ware Forth die beste Methode. Aber ist Micromouse wirklich 
ein Programmierwettbewerb? Anfangs war er das vielleicht mal, aber 
schaut man sich einmal an, welche Teams heute daran teilnehmen 
und welche best-practice Methoden eingesetzt werden so haben sich 
die Anforderungen verandert. 

Nicht etwa dass sie komplexer geworden sind, ganz im Gegen- 
teil. Im Laufe der Jahre fand beim Micromouse Wettbewerb eine 
Suche nach einem Minimalismus statt. Die Frage ist, was der ger- 
ingstmogliche Aufwand ist urn den Roboter gerade so ins Ziel zu brin- 
gen. Anders gesagt geht es darum, dass die Teilnehmer ihre Kosten 
senken, also der Aufwand den sie treiben miissen. Man kann sagen, 
dass es bei Micromouse darum geht den billigsten Roboter zu bauen. 
Billig muss nicht unbedingt bedeuten, dass sein RAM nur maximal 10 
kb groB sein darf, Billig kann bedeuten, dass man einen ausgewach- 
senen Laptop mitsamt Onboard Linux und Wifi an den Start bringt. 
Sondern es geht urn die Gesamtkosten die das Projekt erzeugt, also 
wieviel Stunden man braucht urn ein gewunschtes Ergebnis zu erzie- 
len. 

Die Programmiersprache Forth ist besonders stark auf die Pro¬ 
grammierung als solche fokussiert. Also darauf, wie man bare-metal 
die Probleme lost, und vor allem auf Meta-Programmierung. Also 
wie man Bootstrapping Verfahren durchfuhrt. Das heiBt, man schreibt 
sich zunachst einmal einen Interpreter fur eine Domanenspezifische 
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Sprache und entwickelt das zu einem Robot-control-System weiter. 
Dabei fangt man ganz unten an bei der Stackmanipulation und ar- 
beitet sich dann langsam hoch. Aus Sicht der Informatik ein guter 
Ansatz, nur leider wird man damit bei Micromouse scheitern. Es sind 
nicht jene Fahigkeiten auf die es ankommt. Sondern wie man den 
Wettbewerb eher gewinnt ist wenn man einen Bugrracker aufsetzt, 
UML Diagramme zeichnet, Literatur recherchiert und Leute ins Team 
holt die sich mit Marketing auskennen. Anders formuliert, Micromouse 
hat mehr Ahnlichkeit mit einem Business-Projekt was in einem Un- 
ternehmen ausgefuhrt wird und wo es Management-Entscheidungen 
als mit einem lowlevel Hacking Projekt. 

Ich glaube, dass Forth und vieileicht sogar C beim Micromouse 
Wettbewerb nichts verloren haben. Es sind Sprachen die veraltet 
sind. Sie sind zwar nominell klein und schiank aber nicht im Sinne 
eines schlanken Micromouse Projektes. Das heiBt, wenn man eine 
Programmier-orientierte Herangehensweise wahlt ist die Gefahr groB 
dass man beim Wettbewerb scheitert. Besser ist es, in groBeren Di- 
mensionen zu denken und mit einer UML zentrierten / Projektorgani- 
sation an das Thema heranzugehen und sich nach dieser Zielsetzung 
fur konkrete Technologien entscheiden. Wenn es Microcontroller mit 
vorinstalliertem Linux gibt, dann sollte man sie einsetzen. Sie erle- 
ichtern die Dinge ungemeint. Wenn es Librarys bei github gibt, nur her 
damit. Wenn man irgendwo einen Robotersimuiator in 2D Auftreiben 
kann umso besser. Man sollte Micromouse eher aufziehen wie ein 
GroBprojekt, also wo man erstmal Spitzenprogrammierer aus den 
USA einfliegen lasst, die vor dezidierte Workstations setzt und wenn 
es dann wissenschaftliche Probleme gibt werden die mit Mathematik- 
ern, Soziologen und Kunstlern ausdiskutiert. 

Rein formal ist die Software urn einen Roboter durchs Labyrinth zu 
schicken erstaunlich kompakt. Wenn man sich Muhe gibt kann man 
den Assemblercode in weniger als 50 kb unterbringen. Urn jedoch 
diesen Code zu schreiben reicht es nicht aus, sich in ein Forth Sys¬ 
tem einzuloggen und auf der Textkonsole einige Words einzugeben. 
So bekommt man den Code nicht erstellt. Das darf eher als Antipat¬ 
tern bezeichnet werden. Sondern Sourcecode wird in dezidizierten 
Programmierprojekten erstelit, wo man also eine lernende Organisa¬ 
tion aufbaut und Strukturen schafft damit diese nicht nur den Code 
schreibt sondern sich auch das notige theoretische Wissen aneignet. 

Leider sind klassische Lehrangebote an den Universitaten noch 
auf eine reine Programmierausbildung fokusiert. Wo also anhand 
von konkreten Programmiersprache ein Maze-Solving Algorithmus 
vorgestellt wird und der dann zur Ubung auf einem Roboter imple- 
mentiert wird. Wer so an die Sache herangeht hat bereits verloren. 
Das Problem lautet, dass ein 100 Zeilen Programm nicht ausreicht fur 
einen Roboter. Es geht nicht urn das Programmieren als solches son¬ 
dern urn das Erfinden von Algorithmen, das beseitigen von Fehlern 
und das Dokumentieren der Software. Anders formuliert, wenn man 
Micromouse richtig angeht, ahnelt es eher dem Schreiben einer Diplo- 
marbeit, wo man also das Thema untersucht und Programmieren 
darin nur eine Nebenbedeutung besitzt. 

Der Witz ist, dass die Standard-Algorithmen und die Standardpro- 
grammiersprachen alle verfugbar sind. Wer heute from Scratch einen 
Micromouse Roboter bauen will, hat eigentlich alles was er benotigt: 
Compiler, Interpreter, Programmiersprachen, Assembler, Pathplan- 
ner, Vision Systeme, High-Level-Planner, PDDL, 16 bit Microcontroller 
usw. Die Kunst besteht darin, dass alles zu komibinieren zu einem 
lauffahigen ganzen und auBen herum auch noch das Team bei Laune 
zu halten. Das ist die eigentliche Kernkompetenz auf die es ankommt. 

Lines of Code Warum sich nicht die Sprache Forth sondern die viel 
komplexere Kombintation aus C plus Unix hat durchsetzenk konnen 
hat einen simplen Namen: lines of Code. Damit ist gemeint, dass die 
Anforderungen an Software gewachsen ist und die einzige Moglichkeit 


mit den Bedurfnissen der User mitzuhalten besteht darin, wenn man 
die Codezeilen erhoht. So besteht der Linux Kernel heute bereits aus 
20 Mio Codezeilen, Tendenz steigend. FOr Computerspiele und Inter- 
netbrowser gilt das selbe. Das mag jetzt etwas uberraschen weil nach- 
dem man Linux startet eigentlich nicht viel passiert, es laufen einige 
Statusmeldungen uber den Bildschirm und das wars auch schon. Man 
konnte diese Meldungen gut in einer 2 kb groBe Zip Datei unter¬ 
bringen und den Sourcecode von Linux betrachtlich einstampfen. Die 
Schwierigkiet besteht darin, dass kleine schlanke Programme nicht 
wirklich klein und schiank sind. Wenn man einen Forth Interpreter 
in 2 kb vorliegen hat ist das zwar formal gesehen ein Betriebssys- 
tem inkl Programmiersprache defakto ist es fur den user damit nicht 
moglich seine Ziele zu erreichen. Es ist nicht moglich, durch kleinere 
Modifikationen des Forth Interpreters ihn dazu zu bringen, Webseit- 
en anzuzeigen oder Spiele zu spielen. Es hat seinen Grund warum 
reale Projekte aus vielen Codezeilen bestehen. Schon kleinere Com¬ 
puterspiele kommen auf 1 Mio Lines of Code. Und es gibt bis heute 
keine Methode wie man das andert. Ganz im Gegenteil, als Anfang 
der 1990'er die objektorientierte Programmierung erfunden dann nur 
zu dem Zweck die Anzahl der Codezeilen weiter zu erhohen. Es 
reichte nicht aus, einfach nur in MS-DOS irgendwelche Spiele zu 
haben, sondern die Anwender wollten ab den 1990’er Mehrfenster- 
Betriebsssysteme mit komfortablen Buttons und verschachtelten Pull¬ 
down Menus. 

Leider wurde Forth nicht dafur geschaffen groBe Codemengen 
einzugeben oder zu verwalten. Das beginnt mit der reverse polish No¬ 
tation und zieht sich uber fehlende Array Funktionen weiter. Durch 
die Abwesenheit von Standards fehlte es auch an Bemuhungen die 
ein Betriebssystem zum Ziei hatten, wodurch es unter Forth keine 
leistungsfahigen IDEs wie den Emacs gibt. Kurz gesagt, mag in den 
1970'er Jahren noch weitestgehend Gleichstand zwischen Forth und 
C gegeben haben (beide Systeme waren extrem kompakt und es 
fehlte an Bibliotheken) hat sich die Lage zuungunsten von Forth en¬ 
twickelt. Forth wird diesen Ruckstand niemais aufholen konnen. Die 
Menge an Code die fur C/Java/C++ usw. produziert wird ist es urn 
einiges groBer was an Forth Code neu geschrieben wird. 

Forth ist keineswegs uninteressant als Sprache. Unter den Toylan- 
guages gehort sie zur Nr. 1 und es ist lehrreich sich damit zu beschafti- 
gen. Nur, in erster Linie erfullen Computersprachen einen Zweck. Die 
Entwicklung der Software verlauft Usergetrieben und hier kann Forth 
nicht mithalten. Es gibt schlichtweg keine User die an Forth Program- 
mierer herantreten und Anderungen haben wollen. Sondern die User 
wollen professionelle Software auf ihrer Hardware haben. 

Die Schwierigkeit mit Forth Sourcecode ist, dass er im Zweifel 
keineswegs kleiner ist, als vergleichbarer Code in C. Der selbe Algo¬ 
rithmus einmal in C und einmal in Forth implementiert nimmt ungefahr 
den selben Platz ein. Schon die Sprache Python ist mit dem Anspruch 
gescheitert, die Anzahl der CodegroBe zu reduzieren. In der Prax¬ 
is kann man zwar mit Python rund 10% weniger Zeilen nutzen und 
trotzdem das gleiche tun, aber ein Projekt mit 1 Mio Lines of Code 
reduziert sich davon nur minimal. Bei Forth gilt gleiches. Wenn man 
sich bemuht kann man mit etwas Ubung die Words nebeneinander 
und nicht untereinander schreiben, aber den Codeumfang wird man 
dadurch nicht reduzieren. Auch Forth ist eine prozedurale Program¬ 
miersprache, was bedeutet, dass man Unterprogramme schreibt und 
nach dem Teile und Hersche Paradigma die angeht. 

8.3 Es gibt zuwenig Challanges 

Die akademische informatik allgemein aber auch Forth im Beson- 
deren haben ein Problem: es wird nicht unterschieden zwischen Sinn 
und Unsinn. Genauer gesagt gibt es jede Menge Theorie daruber 
wie Computer funktionieren und wie man sie programmiert aber 
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nur wenig belastbare Fakten. In dieser Atomosphare des anything 
goes bluhen naturlich auch Pseudowissenschaftliche Theorien die 
wissenschaftlich auftreten aber keinen Wert besitzen. Um diese zu 
identifzieren sind Coding-Challanges die beste Methode. Interessan- 
terweise gibt es gerade zu den Kernthemen keine solche Chal¬ 
lenges. Ich habe mal speziell im Bereich Forth nach einer Coding- 
Challanges gesucht: Fehlanzeige. Und Forth wird gerade im Bere¬ 
ich der akademischen Informatik als letztes Bollwerk verstanden hin- 
ter dem man sich verschanzt und mit dessen Hilfe man abgesicherte 
System entwerfen will und die Computer von morgen. Eigentiich ware 
eine Forth Coding Challange sehr simpel: es gibt eine Aufgabe, wie 
schreibe einen Primzahlgenerator in einer 1 Stunde und dann schaut 
man wer der beste Programmierer ist und wie die Losung aussieht. 
Solche Challanges werden nicht veranstaltet. Auch bei Micromouse 
wo man Forth gut einsetzen konnte, fehlt es ausgerechnet an Forth 
Projekten. Nicht viel anders sieht es bei einem anderen Thema der 
Informatik aus, wo sich viele Leute an den Hochschulen mit beschafti- 
gen: Neuronale Netze. Auch dort wird viel daruber geschrieben auch 
sehr neue und avant-Garde Forschung. Komischerweise fehlt es ahn- 
lich wie bei Forth jedoch an Programmierwettbewerben. Wo man al¬ 
so ein neuronales Netz aufsetzt und das dann konkrete Dinge tun 
soil. Ein guter Anfang besteht darin, eines zu programmieren was 
Primzahlen losen kann ... 

Das Fehler solcher dezidierten Wettbewerbe lasst sich nichts ah- 
nen. Vermutlich werden sie deshalb nicht durchgefuhrt weil man ins- 
geheim Angst hat vor den Resultaten. Weil plotzlich das Buchwissen 
was die Akademiker seit 30 Jahren angesammelt haben auf dem Pruf- 
stand steht und wenn ein Student die Aufgabe nicht Ibsen kann, ist 
womoglich nicht der Student daran schuld, sondern Neuronale Net¬ 
ze sind doch keine guten Mustererkenner wie es immer heiBt. Ich 
habe nichts gegen Forth oder neuronale Netze, sondern ich mochte 
das wissenschaftliche Umfeld kritisieren indem sie unterrichtet wer¬ 
den. Es macht keinen Sinn nur theoretisch zu Themen der Infor¬ 
matik zu forschen und gepeerreviewte Paper bei Elsevier zu verof- 
fentlichen wenn es keine Moglichkeit gibt, Theorien zu wiederlegen. 
Das interessante bei Programmieraufgaben ist, dass es dort eben 
nicht darum geht etwas zu verstehen und sich mit jemand anderem 
der es ebenfalls verstanden zu unterhalten, sondern bei Programmier¬ 
wettbewerben geht es um eine soziale Konkurrenzsituation bei dem 
Verlierer produziert werden. Also Teilnehmer, die es nicht geschafft 
haben und die versuchen dafur eine Ausrede zu finden. Dieser Fte- 
flektionsprozess ist wichtig, nicht so sehr fur den einzelnen, sondern 
fur das Fach insgesamt. Daruber wird es mbglich schneller zu erken- 
nen, welche der geschatzt 100000 Paper die uber neuronale Netze 
geschrieben wurden, Unsinn enthalten und welche nicht. Aktuell sind 
alle gleich gerankt und der einzige Bias bei Google Scholar ist die Zi- 
tierhaufigkeit. Wenn aber alle den Kaiser wegen seiner Kleidung loben 
wird niemand es wagen zu widersprechen. Die Informatik ist auf Mittel 
der Selbstreflektion angewiesen, nur so kann man steuern wohin die 
Reise gehen soil 

Schauen wir mal an, wie derzeit uber das Thema Neuronale Net¬ 
ze diskutiert wird. Ublicherweise ladt sich jemand einen Neuronalen 
Netz Simulator aus dem Netz herunter, stellt dort ein er mochte 3 
Hiddenlayer und 10 Eingangsneuronanen haben, trainiert ein wenig 
mit Beispieldaten und stellt test, dass der Fehlerwert sich nicht weiter 
senken lasst sondern einfriert. Wenn er jetzt bei Stackoverflow nach- 
fragt warum sind die Antworten entlarvend. Der erste meint, dass der 
Fragesteller das Thema nicht richtig verstanden hatte, der nachste 
meint die Frage sei zu allgemein gehalten und er brauchte weitere 
Informationen uber die Software, der nachste glaubt zu wissen, dass 
man die Lernrate irgendwo einsteilen kann und der letzte hat uber- 
haupt keinen Plan kennt aber ein gutes Buch was er empfehlen kann. 
Nur, wirklich vorangekommen ist dabei niemand. Im Grunde war das 


ganze ein unverbindliches Gesprach was aufgezeigt hat, dass es of- 
fenbar niemand gibt der sich naher damit beschaftigt hat. Wurde man 
hingegen einen Wettbewerb durchfuhren wo alle 10 Teams an der 
konstanten Fehlerrate scheitern, die sich nicht weiter verbessert lasst 
hatte die Informatik ein echtes Problem. Jetzt konnte man nahmlich 
mit der Ursachenforschung beginnen und die Theorie der neuronalen 
Netze an sich hinterfragen. Genau dieser schonungslose Umgang mit 
Realitat ist derzeit eher die Ausnahme. 

9 Automaten 

9.1 Registermaschinen aka Random Access Machi- 
nen 

Ein Forth Chip basiert ublicherweise darauf, dass es einen instruc¬ 
tion Pointer gibt, welcher den nachsten Befehl spezifziert und einen 
Stack indem sich Daten befinden die verarbeitet werden. Haufig wird 
gesagt, das musse so sein, und es sich um das kleinst-mbgliche 
Berechnungsmodell handeln wurde. Also das Standard-Verfahren um 
eine CPU zu beschreiben. Das ist so nicht korrekt. Eine Weiteren- 
twickelte Form der Stackmachine ist eine Registermaschine, dort gibt 
es neben dem Befehlscounter auch einen Speichercounter. Genauer 
gesagt kann die CPU sowohl auf Befehle als auch auf Daten wahl- 
frei zugreifen. Mit wahlfrei ist gemeint, nicht nur das oberste Element 
eines Speichers ansprechen sondern beliebige Elemente. Und hier 
nahern wir uns den heute verbreiten Mikroprozessoren welche ganz 
uberwiegend als Registermaschine ausgelegt sind. 

Um sich den Unterschied vor Augen zu fuhren kann man sich ein 
Python Array vorstellen. Einmai die Variante, bei dem man ganz nor¬ 
mal darauf zugreift also “print temp]2]” und dann eine eingeschrankte 
Version bei dem man nur jene Elemente lesen / schreiben kann die 
sich am Ende befinden “print temp[-1]”. Schaut man sich reale Python 
Programme an, so wird man sehen, dass die Variante mit dem wahl- 
freien Zugriff beliebter ist, sie lasst sich komfortabler benutzen. Aber, 
grundsatzlich kann man auch nur mit einem Stack arbeiten. Das ist 
jedoch anspruchsvoller zu programmieren. 

Stack vs Register In einem Punkt sind sich Stackbased Machines 
und Registermachinen ahnlich. Sie haben beide einen Programm- 
counter. Damit ist eine Speicheradresse gemeint, an der der nach¬ 
ste Befehi wartet. Auf welche Daten ein Opcode dann zugreift, ist 
unterschiedlich. Bei einer Stackbased-CPU kann der Befehl nur auf 
den Stack zugreifen und dort nur auf das oberste Element. Bei einer 
Registermaschine hingegen auf praktisch jede Stelle im Speicher. Der 
Speicher wird jeweils in die Register eingeblendet und wenn das nicht 
funktioniert gecached. 

Aus Sicht der theoretischen Informatik ist die egal ob man eine 
Stackmachine oder eine Registermachine verwendet. In beiden Fallen 
lasst sich ein Programm abarbeiten. Der Unterschied besteht jedoch 
aus Sicht des Engineering, also wenn man einen moglichst effizien- 
ter Computer bauen mochte. Flier ist die Stackmachine im Vorteil. 
Eine Registermaschine ist nur die zweitbeste Moglichkeit eine Turing- 
Maschine in Hardware zu realisieren. Es ist prinzipiell mbglich aber 
die Ausfuhrungszeiten sind erhoht. 

Der Grund warum sich im Mainstream die Registermaschine 
durchgesetzt hat, liegt darin begrundet, dass man dort leichter C- 
Compiler fur schreiben kann. Es gab zwar Versuche auch fur Stack- 
machinen C-Compiler zu entwickeln doch ohne Erfolg. Am effizien- 
testen lassen sich diese Maschinen in Forth programmieren und 
ublicherweise wird der Code manuell programmiert. 

Ublicherweise grenzt sich die Forth-Community von der ubrigen 
Informatik scharf ab. Doch so gro(3 sind die Unterschiede gar ncht. 


24 



Sowohl die Java Virtual Maschine als auch die Python Virtual Mas- 
chine sind als Stackmachine implementiert. Um sie auf einer Reg- 
istermaschine auszufuhren benotigt man einen Interpreter. Es ist 
also keineswegs unmoglich zwischen Stack- und Registermachine 
hin- und herzuubersetzen. Wenn man Python Sourcecode in Python 
Bytecode ubersetzt, wird eine objektorientierte Hochsprache in eine 
Lowlevel Stackmachine konvertiert, und wenn man Python Bytecode 
auf einer x86 CPU ausfuhrt, wird eine abstrakte Stackmachine gegen 
eine x86 Registermachine gemappt. 

Der Grund, warum Java und Python sehr junge Plattformen sind 
hat exakt mit dieser Ubersetzung zu tun. Ublicherweise wurde bevor 
es Java gab, so gearbetiet: der Programmierer hat seinen Code in 
C/C++ geschrieben, dieser wurde von einem Compiler in Maschinen- 
code ubersetzt und zwar fur eine Registermaschine. Bis heute kann 
gcc beispielsweise nicht fur Stackmachinen Code erzeugen. Die Auf- 
gabe gilt ais zu anspruchsvoll und auch C to Forth Compiler gibt es 
nicht. 

Dann kam Java und hat alies verandert. In dem Moment wo man 
sich fur eine virtuelle Maschine entscheidet erhalt man 2 Layer: einmal 
die Programmiersprache Java als solche, also schon objektorientiert 
mit machtigen Bibliotheken und darunter dann die Laufzeitumgebung 
die sehr systemnah programmiert wird. Und die Java-Runtime-Engine 
war dann auch der Ort wo an erstmalig leistungsfahige Stackmachine 
to Registermachine Compiler entwickelt wurden. Als Input wurde an- 
ders als bei fruheren Compilern nicht etwa C oder C++ verwendet, 
sondern der Bytecode der schon da war. Und der wurde dann in einem 
zweiten Schritt auf x86 Registermaschinen gemappt. 

Es ware durchaus moglich, eine JVM fur einen Stackprozessor zu 
entwickeln. Das gleiche gilt fur Python und fur C#. Das heiGt, man 
wurde den Bytecode aus einer virtuellen Stackmachine auf eine ph- 
ysische Stackmachine mappen. 

Ich glaube, auch in Zukunft wird es keine C to Forth Compiler 
geben, die Aufgabe ist zu anspruchsvoll. Aber was durchaus denkbar 
ware, das ist eine JVM fur den GA144 Arraycomputer. Also eine En¬ 
gine welche Java Code auf einem Forth prozessor ausfuhrt. 

Flier kommen wir zu der grundsatzlichen Motivation warum Java er- 
funden wurde. Java ist nicht einfach nur eine Programmiersprache, 
sondern Java zerteilt einen klassischen Compiler in zwei Ebenen. 
Java->Bytecode und Bytecode->Maschinecode. Dadurch wird die 
Komplexitat drastisch gesenkt und man kann jeden Layer einzeln 
optimieren. Aktuell ist es so, dass alle Virtuellen Maschinen (Java, 
Python und C#) aussschlieGlich fur Registermaschinen x86 Code 
erzeugen. Vorstellbar ware es aber, wenn man die Virtual Maschine 
aufteilt. Ein Backend fur x86 Maschineinstructions und eines fur Forth 
Chips. Damit hatte man dann eine extrem leistungsfahige Pipeline wo 
die Softwareentwickler in Java programmieren konnen und der Code 
dann auf Forth CPUs ausgefuhrt wird. 

Mit der traditionellen Compilertechnologie a la C++ ist sowas nicht 
moglich. Ein solches Projekt ware gigantisch, es ist nicht handel- 
bar. Wenn man es jedoch mit Java im FHinterkopf betreibt konnte es 
klappen. Die Anforderungen ein JVM fur einen Forth Backend zu 
schreiben ist uberschaubar. 

Das lauft darauf hinaus, eine Programmiersprache zu entwickeln 
die schneller abgearbetiet wird als C. Technisch ist das machbar mit 
der oben beschriebenen Methode. Aber, auch heute schon kann man 
in speziell entwickelten FPGA Schaltungen etwas ahnliches machen. 
Wo man also auf eine Programmiersprache verzichtet und den Al- 
gorithmus gleich als IP Core formuliert. Wenn man den ausfuhrt kann 
man jedes C-Programm ubertrumpfen. Das ganze ist also weniger ein 
konkretes Problem was sich stellt sondern gibt eher die Richtung vor 
wohin sich die Computertechnik entwickelt. Das heiGt, es ist vorstell¬ 
bar, dass JVM Plattformen weiter verbessert werden und dass die 
CPUs ebenfalls sich mehr auf diesen Trend werden einlassen. In der 


letzten ARM Generation gibt es beriets ein Bit was man aktivieren 
kann um Java ByteCode nativ auszufuhren. Laut einer Messung war 
der Effekt gering (10% schnellere Codeausfuhrung). Wenn man das 
ganze weiterentwickelt, dOrfte sich da noch mehr Performance raus- 
holen lassen. 

Das Problem ist ein anderes: letztlich sind diese Steigerungen 
nichts neues. Sondern das Moorsche Gesetz sieht ja gerade vor, dass 
sich jedes Jahr die Leistung verbessert. Und der Wechsel von Regis¬ 
ter auf Stackmachinen plus die dazugehorigen Compiler sind nur ein 
Spielfeld unter vielen. 

Reizt man das alles aus, bleibt alies beim alten. Das heiGt, vielleicht 
hat man irgendwann eine JVM die auf einem GA144 Forthprozessor 
mit 1 Watt in hoher Geschwindigkeit lauft und man kann trotzdem in 
Java darauf programmieren. Aber wen interessiert das? Wenn man 
keinen Java Code hat, nutzt die verbesserte Flardware gar nichts. 

Letztlich ist also Java und Forth, Stackmachinen und Register¬ 
maschinen alle ein und dasselbe. Nicht auf der technischen Ebene 
wie es im Detail funktioniert, sondern auf einer kulturellen Ebene. Es 
geht im Kern darum, Maschinen effizienter zu machen, CPUs zu en¬ 
twickeln und Code auszufuhren. 

9.2 Stackmachine vs. Registermachine 

Im Jahr 2016 ist ein Peper erschienen was virtuelle Stackmaschinen 
mit virtuellen Registermaschinen vergleicht [3] und zu dem Schluss 
kommt, dass Registermashinen schneller sind (um 30%). Speziell fur 
diesen Vergleich wurden zwei Virtuelle Maschinen in Software pro¬ 
grammiert, und diese auf realer Flardware ausgefuhrt. Es ging konkret 
um die Frage, ob die Java-Virtual Maschine (welche als Stackmas- 
chine aufgebaut ist) nicht durch eine Registermaschine ersetetzt wer¬ 
den sollte. 

Das interessante an dem Vergleich ist, dass er fur sich betra- 
chtet korrekt ist, aber mit sehr eingeschrankter Sichtweise das Thema 
bearbeitet. Ein fairer Vergleich sieht so aus, dass man anhand der 
Performance per Watt Benchmarks einen Vergleich anstellt. Denn, 
um eine Registermaschine in Flardware zu realisieren braucht man 
mehr Transistoren als wenn man eine Stackmachine in Flardware re- 
alisiert. Wenn man den Vergleich nach dieser MaGgabe ausfuhrt ist 
das Ergebnis eindeutig zugunsten der Stackmaschinen. In mehreren 
Powerpoint Vortragen zum GA144 Chip wurde die Performance per 
Watt MaGzahl verwendet. 

Anders ausgedruckt, es ist technisch moglich eine Registermas¬ 
chine zu bauen, die effizienter ist als eine Stackmaschine, sondern 
um sowas zu “beweisen” muss man schon ziemlich tief in die Trick- 
kiste greifen was mit Wissenschaft jedoch nichts mehr zu tun hat, 
sondern eher mit Ideologie. Nein, das einzige Gegenargument was 
Stackmachinen spricht ist, dass es dafur keine Flochsprachencompil- 
er gibt. Der GA144 Chip ist nutzlos, weil sich darauf kein Java Code 
ausfiihren lasst. Das ist ein faires Argument. 

Die Nichtverfugbarkeit von Flochsprachencompilern ist jedoch 
keine technische Eigenschaft sondern hat etwas mit kulturellen Tra- 
ditionen zu tun. Das man also irgendwie glaubt, es wurde nicht gehen 
und es wurde nichts bringen und deshalb in dieser Richtung nicht 
geforscht wird. Tatsachlich sind Stackcomputer die Zukunft, sie sind 
um einiges machtiger. Insbesondere wenn man bedenkt, dass dort die 
nachsten Features wie Arrayprozessoren und clockless Ausfuhrung 
schon heute ais Prototypen realisiert wurden, wahrend das bei Reg¬ 
istermaschinen noch nicht geht und sehr viel komplizierter ware. 

Gehen wir etwas naher auf den GA144 Chip ein. FlardwaremaGig 
schlagt er Intel Prozessoren um Langen. Er verbraucht weniger En- 
ergie pro Operation, ist durch das Zusammenshalten von mehreren 
Elnheiten nach oben skalisiert und kann deutlich preiswerter pro- 
duziert werden. Im Grunde ist der GA144 Chip eine Art von Xeon 
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Phi, nur dass es nicht 3000 US$ kostet sondern nur 30 US$. Das sich 
der Chip nicht durchsetzt hat keine technischen Grunden sondern es 
sind Wettbewerbsrechtliche Fragen. Wurde man sowas auf den Markt 
bringen, ware Intel pleite. 

Halt, nicht ganz so schnell. Einen Nachteil hat die GA144 CPU. 
Man muss sie zwingend in Forth programmieren. Das ist jene Pro- 
grammiersprache die nachweislich (ich habe es selber versucht) sehr 
schwer zu erlernen ist. Forth ist eine Zumutung, insbedonere wenn 
man objektorientiertes Programmieren gewohnt ist. Man kann in Forth 
durchaus Programme schreiben, aber das Coden, Testen und De- 
buggen geht urn einiges langsamer. Ich wurde mal schatzen, dass 
man fur ein Forth Programm rund lOOx langer benotigt als fur das 
selbe Programm in Python bis man es programmiert hat. Und das ist 
in der Tat ein echter Nachteil. 

Der Schlussel um den Markterfolg von Forth Chips zu ermoglichen 
sind JVM Engines fur Stackmaschinen. Also Systeme welche Java- 
Bytecode in Forth-Maschineninstructions ubersetzen konnen. Soet- 
was zu programmieren ist anspruchsvoll aber moglich. Es ist 
wesentlich leichter als wurde man einen Java-to-Forth Converter 
schreiben. Weil, der JVM Bytecode ist bereits fur eine Stackmaschine 
optimiert, man kann ihn gut auf eine physische Stackmaschine map- 
pen. Damit wird es moglich, die Performance Vorteile eines GA144 
Chips an die Java-Programmier-Community hochzureichen. .Das man 
also in seiner Lieblingssprache ganz normal Klassen anlegt und Java- 
Libraryies nutzt, das dann aber auf einem Forth Chip ultraschnell aus- 
fuhrt. 

Diese Technologie durfte die Hardware-lndustrie vor die selben 
Schwierigkeiten stellen wie Linux es mit Microsoft gemacht hat. Es 
wird ein hoher Vorteil fur die Kunden entstehen wahrend die Hersteller 
klassischer Hardware vor Probleme gestellt werden. 

9.3 Uber Kellerautomaten und Mealy Machinen 

Computer waren schon immer hierarchisch aufgebaut. In dem Sinne 
dass auf der untersten Ebene Nullen und Einsen existieren und erst 
viele Ebene daruber dann Betriebssysteme und Software ins Spiel 
kommt. Einmal lasst sich diese Hierarchie historisch erklaren, in dem 
Sinne dass es in den 1950’er noch keine GUI Betriebssysteme gab, 
aber auch wenn heute from Scratch neue Computer baut wird diese 
Hierchie sichtbar. Besonders schon kann man das am Beispiel von 
Forth betrachten. Ein Forth System ist von der Hardware sowie der 
Software ein Lowlevel Computer. Also ein System wo noch sehr vieles 
nicht existiert. 

Die einfachste Methode um Computer zu bauen ist, wenn man 
auf Software komplett verzichtet und stattdessen die Ablauflogik di- 
rekt in Hardware realisiert. Hierbei spricht man von einer State- 
Machinen. Diese lassen sich direkt aus Logik-Baulelementen erzeu- 
gen. Auch State-Machines sind turing-machtig und zwar weil man ex- 
trem komplexe Verzweigungen aufbauen kann die exakt das tun was 
ein normaler Computer auch kann. Die Frage ist nur: wer program¬ 
miert solche State-Machines? Und genau hier liegt die Notwendigkeit 
nach mdglichen Alternativen zu suchen. Genau genommen diente 
die Weiterentwicklung der Computer seit seinen Anfangen dazu, 
dass Programmieren zu erleichtern. Konkret bedeutet es, dass Hard- 
waremaBig mindestens seit den 1930'er klar war wie man leis- 
tungsstarke Computer baut. Bereits damals gab es Logikbausteine 
die schnell genug schalten konnten. Die Schwierigkeit bestand darin, 
dass es keine Programme fur diese Computer gab. 

Wenn man in Hardware realisierte State-Machine um weitere Ele- 
mente erweitert wie einen Stack erhalt man einen Kellerautomaten. 
Erweitert man diese um Register erhalt man die Harvard Architek- 
tur, erweitert man diese um Microcode entsteht ein CISC Prozessor, 
dieser wird dann um ein BIOS, C-Compiler und Betriebssystem er¬ 


weitert und irgendwann erhalt man heute ubliche PCs, die also nach 
dem Einschalten einen Webbrowser plus Python anzeigen wo man 
auf einer sehr hardwarefernen Abstraktion Befehle in den Computer 
eingeben kann. In dem Sinne dass sich fast als Pseudocode Algo- 
rithmen in einer Scriptsprache formulieren lassen und das man an 
Google anfragen senden kann wie “warum ist das Wasser nass?”. 

Ein Forth System kann man em ehesten als turing-machtigen Com¬ 
puter auf der Stufe eines Kellerautomaten bezeichnen. Laut Wikipedia 
besteht ein Kellerautomat aus 2 Stacks und sieht der Abbildung 
entsprechend einer Turing-Machine ahnlich. Nur dass sich neben dem 
Schreiblesekopf noch eine Erweiterung befindet namens Stack. 

Minimal instruction set computer Ublicherweise gibt es in der In- 
formatik einen Konsens daruber ab wann ein Machinenmodell Sinn 
macht. Man unterteilt Computer in Lerncomputer welche theoretisch 
untersucht werden und praktisch relevante Machinen welche pro¬ 
grammiert werden konnen. So ist zwar bekannt dass State-Machinen 
echte Computer in dem Sinne dass sie Schleifen haben und if-then- 
Befehie verarbeiten es ist jedoch nicht moglich damit etwas sinnvolles 
anzufangen, also Betriebssysteme fur diese Computer zu entwickeln. 
Registermachinen gelten sowohl theoretisch als auch praktisch als 
sinnvoll, man kann sie wirklich programmieren. Und hier kommt Forth 
ins Spiel. Aus Sicht der Mainstream informatik handelt es sich um 
Minimal instruction set computer die keine praktische Bedeutung be- 
sitzen. Man nimmt an, dass man sie nicht programmieren kann, jeden- 
falls nicht okonomisch sinnvoll. Die Forth Community behauptet hinge- 
gen, dass es sehr wohl geht und hat dafur eine eigene Sprache na¬ 
mens Forth entwickelt. Die Frage lautet: wer hat Recht? Ist Forth eine 
rein akademische Sprache mit der man die Funktionsweise von Keller¬ 
automaten erlautert Oder kann man damit echte Probleme losen? 

Auf github gibt es ein Projekt namens “movfuscator” 16 dass C- 
Quelltext so aufbereitet, dass es auf einem Computer lauft, was nur 
den Mov Befehl kennt. Verwendet wurde dabei der LCC Compiler. Das 
neue Assembler Programm (mit den Mov-Befehlen) wird dann auf ein¬ 
er x86 Archtektur ausgefuhrt. 

Obwohl es nicht als Forth Projekt gestartet ist, geht es ungefahr 
in diese Richtung. Die Annahme lautet, dass die Hardware ein Mini¬ 
mal Instruction Set Computer ist. Also ein System was nach heutigen 
MaBstaben als nicht-programmierbar gilt, es sei denn jemand ist so 
schlau einen C-Compiler dafur zu schreiben. Genau das ist offenbar 
moglich. Dadurch kann man selbst diese minimale CPU so program¬ 
mieren wie eine normale x86 Architektur. 

Verallgemeinert man die Losung kann man sagen, dass die C- 
Programmiersprache den Unterschied definiert zwischen einem the- 
oretischen und einem realen Computer. Wenn es fur eine CPU 
einen C-Compiler gibt der dafur Machinencode erzeugen kann ist es 
moglich diese CPU auf High-Level-Ebene zu programmieren. Also all 
die Spiele und Primzahlensuchalgorithmen die es schon gibt darauf 
auszufuhren. Wenn es hingegen nicht gelingt, dann gilt diese CPU als 
nicht praktisch relevant. Man kann sie zwar lowlevel programmieren 
aber es ist sehr aufwendig. 

10 Okonomische Aspekte 

10.1 Einleitung 

Warum sich Forth nie so recht hat durchsetzen konnen hat damit 
zu tun, dass die dahinterstehende Technologie eigentlich niemand 
benotigt.Will man Forth auf seine Quintessenz zusammendampfen ist 
es nichts anderes als eine Virtuelle Maschine fur einen Stackcom- 
puter. Sie lasst sich in 10 kb C Code programmieren. Oder noch 

16 https://github.com/xoreaxeaxeax/movfuscator 


26 



besser, man schreibt Forth in Forth selbst, so ahnlich wie Pypy nur 
machtiger. Die Frage ist, was soli das? Wo ist der Nutzen? An sich 
besitzt Forth nicht mehr nutzen, als wenn man sich mit dem Busy- 
Beaver Wettbewerb Oder mit Brainfuck die Zeit vertreibt. Es ist eine 
intellektuelle Obung ohne groGe Bedeutung. Warum Forth aber den- 
noch einen Wert besitzt kann man sehen, wenn man den Blick auf 
die okonomischen Elemente der Computerhardware richtet. Es gibt 
hier GroBkonzerne wie Intel und co, welche Unsummen mit ihren 
CPUs verdienen. Wurde man das auf Forth als Standard-Sprache und 
Forth-Chips als Standard-Mikroprozessor umstellen lieBe sich volk- 
swirtschaftlich gesehen sehr viel Geld sparen. Die Prozessoren wer- 
den preiswerter, verbrauchen weniger Strom und leisten mehr. 

Warum sich Forth in einer Nische der Informatik befindet ist simpel: 
es ist so gewollt. Und zwar von den Neoludditen, welche in technis- 
chem Forthschritt ein Problem sehen. Forth ist fur heutige Computer- 
hardware, dasselbe wie ein Benzin-Auto fur die Postkutsche war: eine 
existenzielle Bedrohung. 

Ein wenig naiv ist die Sache simpel: man fertigt Stackmachinen 
in Plardware, programmiert dafur neuartige Compiler und portiert die 
vorhandene Software darauf. Das ganze ist ein typisches Informatik- 
Thema. Dennoch ist der Umstieg auf Forth alles andere als alltaglich, 
der Grund ist dass Forth anders als die ubliche Flardwarebranche 
einen massiven Technologiesprung bedeutet, in dem Sinne dass wie 
aus dem Nichts, die Computer urn ein mehrfaches leistungsfahiger 
werden. Und diese Verbesserung will wohl dosiert sein. Es geht hier 
weniger urn technische als vielmehr urn kulturelle Fragen. Genauso 
gesagt urn einen Kulturschock. 

Obwohl Forth einen groBen Vorteil verspricht verlauft die Ein- 
fuhrung relativ bedachtig. Obwohl der GA144 Chipsatz fast zum Selb- 
stkostenpreis verkauft wird, sind die Einstiegskosten in Forth be- 
trachtlich. Das Problem ist aus der Linux Welt bekannt. Rein for¬ 
mal kann man die neueste Fedora Distribution kostenlos herunter- 
laden und erhalt damit das fortschrittlichste Betriebssystem. Nur, den¬ 
noch ist Linux keineswegs kostenlos, urn es zu benutzen muss man 
sich erst einlesen. Und genau diese Hurde ist bei Forth urn einiges 
hoher. Genauer gesagt haben wir derzeit die paradoxe Situation, dass 
ein GA144 Chip scheinbar aus der Zukunft stammt, nur 20$ kostet, 
als Transputer ausgelegt ist und unglaublich machtig ist, gleichzeitig 
aber die Anzahl der Personen die ihn korrekt Oder auch weniger kor- 
rekt inbetriebnehmen konnen verschwindend gering ist. Das ist nicht 
so ein Problem von Forth, sondern es ist ein Bildungsproblem. Das 
heiBt, es gibt keine guten Bucher dazu, und vor allem keine leichtver- 
standlichen. Diejenige Literatur uber Forth die es gibt, ist nicht zu ge- 
brauchen, bzw. sie muss erst noch geschrieben werden. 

Die Flerausforderung besteht darin, ein komplexes Thema wie 
Forth fur den Mainstream aufzubereiten urn so den Kreis der User 
zu erhohen. Wie das gehen soil ist nicht ganz klar, es gab zwar einige 
Versuche in der Vergangenheit aber erfolgreich waren die nicht. Das 
Problem mit Forth ist, dass diese Programmiersprache nicht im Jahr 
2017 erfunden wurde und jetzt ahnlich wie ein Consumerprodukt in 
den Markt gedruckt wird, sondern Forth war schon immer da. Der Witz 
ist, dass die Literatur uber Forth die 30 Jahre und alter ist, keineswegs 
veraltet ist, sondern technisch immernoch weit in die Zukunft reicht. 
Nicht Forth ist das Problem, sondern die Welt auGerhalb von Forth. In 
enem Vortrag wurde ein Forth Entwicklerboard einmal als der teuerste 
Computer aller Zeiten bezeichnet. Und ja, das ist korrekt. Nicht rein 
formal, weil das Board fur unter 100US$ verkauft wird, sondern teuer 
im Sinne dass man sich das ganze erst erarbeiten muss. Das heiBt, 
man erwirbt das Entwicklerboard und ist damit dann die nachsten 50 
Jahre erstmal ausgelastet. 


10.2 Kosten von Vintage Computern 

Warum historische Computer bis heute faszinieren ist simpel: sie sind 
extrem teuer. Jetzt mag man sich fragen, was an einem ausrangierten 
1541 Diskettenlaufwerk der Marke Commodore den Preis groBartig 
hochtreibt, weil auf die Floppydisk ja nur 170 kb draufpassen, aber 
genau das ist der entscheidene Punkt. Urn diese Plardware sinnvoll 
einzusetzen muss man aus heutiger Sicht sehr viel darumherum- 
basteln. Theoretisch kann man heute immernoch auf einem C-64 
Texte schreiben und im Internet surfen. Aber vorher muss man er¬ 
stmal die benotigte Software komplett neu programmieren. Standard- 
Software lauft da nicht drauf. 

Innerhalb der Vintage Computing Szene besitzen Stackmachinen 
einen besonderen Reiz. Sie waren schon zu Zeiten ihrer Einfuhrung 
eine Absonderlichkeit, auch in den 1980’er gab es fur den Novix Micro¬ 
controller kein Softwareangebot. Stackcomputer sind also nochmals 
eine Steigerungsform in Sachen Kostentreiber. Will man sie heute 
in Betrieb nehmen wird es richtig teuer. Technisch gesehen ware es 
moglich, aber wer hat die benotigten Ressourcen? Das Spielen mit 
der idee ob es nicht doch gelange aus einem Forth-Chips die letzten 
Resserven herauszulocken ist genau das, was bis heute an dieser 
Technologie fasziniert. 

Mit diesem Plintergrundwissen kann man leicht definieren was 
Fortschritt bedeutet. Es geht darum die Kosten zu senken. Damit 
sind die Kosten fur Plardware, Software und Projektkosten gemeint, 
also wie aufwendig es ist ein bestimmtes Ziel zu erreichen. Wieviel 
man erklaren muss bis ein AuBenstehender es verstanden hat. Das 
interessante an Vintage Computern ist, dass sie in ihrer jeweiligen 
Zeit als fortschrittlich wahrgenommen wurden. Der C-64 war einer 
Lochkartenbuchungsmachine haushoch uberlegen. Es gab Standard- 
programme mit denen man sofort losarbeiten konnte. Aus heutiger 
Sicht jedoch ist der C-64 sehr teuer. Obwohl er nur 64 kb Arbeitsspe- 
icher besitzt ist seine Inbetriebnahme aufwendig und die Program- 
mierung auch. Anders formuliert, ein Topmoderner Intel Xeon Server 
fur 10000 US$ ist urn einiges preiswerter als wenn man versucht das¬ 
selbe mit einem Commodore 64 zu erreichen. Obwohl Technologien 
wie Java, 14 nm Fertigung und Linux extrem kompliziert klingen sind 
sie doch einfacher als eine MOS 6502 CPU. 

11 Abschnitte 

11.1 Forth ist kein Joke 

Neueinsteiger unterschatzen Forth. Sie glauben, es ware keine 
richtige Sprache sondern nur ein Witz. Wo sich also Leute daruber 
lustig machen, wie jemand Forth nicht versteht urn dann in einem 
Forum urn Hilfe zu fragen. Generell kann man jedoch sagen, dass 
es auGerhalb von Forth mehrere Esoterische Programmiersprachen 
wie Joy, Brainfuck und Plaskel gibt die nicht ernstgemeint sind und 
auch nicht fur den praktischen Einsatz konzipiert wurden. Ubllicher- 
weise zeichnen sich Joke-Programmiersprachen dadurch aus, dass 
sie concative funktioneren so wie der PIP RPN Taschenrechner auch, 
und das sie stackbasiert sind. Wenn man eine neue Sprache entdeckt, 
die ebenfalls nach der umgekehrten polnishen Notation funktioniert 
und auf einem Stack aufbaut kann man fast sicher sein, dass es sich 
dabei urn eine Kunstsprache handelt. Die einzige Ausnahme ist Forth. 
Diese Sprache ist ernstgemeint, die darin erstellten Programme er- 
fullen einen Zweck und das Ziel ist es, in Forth sinnvolle Betriebssys- 
teme wie z.B. bigforth zu programmieren. Auch die Forth Chips wie 
der GA144 sind fur seriose Anwendungen wie neural modelling Oder 
Pligh-Performance-Computing entwickelt. Das es dort keine leistungs- 
fahige RAM Speicher gibt hat nichts mit Forth zu tun, sondern liegt an 
den strikten Exportkontrollen der US-Industrie welche urn ihr geistiges 
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Eigentum in Bezug auf Supercomputing furchtet. 

Was man jedoch feststellt, dass es innerhalb der Forth Communi¬ 
ty einige Komiker gibt, welche nicht wirklich an Forth interessiert sind 
sondern ihre eigene Ziele verfolgen. Diese haben es sich zur Leben- 
saufgabe gemacht, moglichst unsinnige Programme zu schreiben 
Oder schwer verstandliche Programme zu verfassen urn sich dann 
daruber zu freuen, dass sie Neueinsteigern erklaren konnen wie es 
funktioniert. Das ist jedoch die groBe Ausnahme. Forth an sich ist eine 
seriose Sprache die positiv in die Gesellschaft wirkt und wodurch man 
etwas uber Plardware und Software lernen kann. 

Anders als Forth ist Pypy jedoch eine klassische Joke Program- 
miersprache. Diese ist stackorientiert, arbeitet mit der umgekehrten 
polnischen Notation und ist fur echte Projekte nicht zu gebrauchen. 
Schon Python selber kann man nur als Witz bezeichnen, Pypy ist noch 
ein lacherlicher. Wurde man die Energie welche in Python abflieBt fur 
Forth Projekte bundeln, hatten wir Weltfrieden. 

Ein weiteres Witzprojekt was nicht taugt ist Micropython. Es han- 
delt sich urn eine Python Virtual Mascine in 200 kb welche auf Micro- 
controllern lauft und wo man ganz normal in Python programmieren 
kann, inklusive Vererbung. Das ganze ist jedoch nicht ernstgemeint, 
sondern Micropython ist lediglich eine Persiflage auf die machtigen 
objektorientierten Features von Forth, wo bekanntlich mit mini-oof.fs 
eine Vererbung standardmaBig dazugehort. 

11.2 Forth langsamer machen 

Forth gilt als eine der effizientesten Moglichkeiten einen Computer 
zu programmieren. C kann man sehr gut mit Forth vergleichen, und 
zwar ist C bedeutend lansamer. Insbesondere wenn man den Ver- 
gleich auf einer dezizidierten Stackmachine ausfuhrt. C ist nur eine 
Plochsprache, Forth hingegen agiert direkt auf Bare Metal. Aus Sicht 
von Forth ist damit alles gesagt, aber nicht so schnell. Ist Forth wirk¬ 
lich die Zukunft? Funktioniert Informatik tatsachlich so, dass es urn 
Effizienz geht? 

Schaut man sich einmal die Entwicklung an die mit UNIX 
angestoBen wurde, so hat sich C nicht deshalb durchgesetzt weil 
es unglaublich effizienten Code generiert und die Z80 CPU ist auch 
nicht deshalb zum meistverkauften Prozessor aller Zeiten geworden, 
weil sie schneller war als eine dezidizierte Forth CPU, sondern diese 
Dinge haben sich durchgesetzt weil sie schon bei ihrer Marktein- 
fuhrung hoffnungslos veraltet waren. Im Grunde sind Registermas- 
chine komplett uberholt. Es ist nicht moglich sie preiswert zu fertigen 
Oder sie parallel zu schalten. Die Technologie hinter Registermaschi- 
nen basiert auf einem veralteten Konzept was den CPU Kern als eine 
Art von Plauptspeicher betrachtet in dem moglichst viele Register das 
Caching ubernehmen. Und Compiler die auf dieser Architektur auf- 
bauen machen es nur noch schlimmer. Diese Ineffizienzen sind je¬ 
doch genau das was man als Programmierer benotigt. Die Gewissheit, 
dass die Maschine der man gegenubersitzt nicht das beste Gerat 
ist was gebaut wurde,sondern aus einer Entwicklungslinie abstammt 
welche als Ausschuss bezeichnet wird. 

Wer in C programmiert hat es mit einem dysfunktionalen System zu 
tun. Mit einem alten Rohrenradio was einen Wackelkontakt hat. Noch 
schiimmer als C ist hochstens noch Python. Nicht nur, dass das Pypy 
Projekt grandios damit gescheitert ist, die Performance zu steigern 
sondern auch die objektorientierten Features von Python sind fehler- 
haft. 

Aber auch hier wieder ist es genau das, was gewunscht ist. Die 
Leute lieben ihr Python, gerade weil es so unglaublich ineffizient ist, 
gerade weil es nicht moglich ist mit Python komplexere Programme 
zu schreiben. Was wir brauchen sind nicht etwa Effizienzsteigerun- 
gen sondern die Zukunft sieht so aus, Sprachen zu nutzen die noch 
viel nutzloser sind als Python und Computer zu bauen, die noch viel 


ineffzienter arbeiten als die heutigen Intel CPUs. Im Grunde ist es fast 
schon eine Frechheit, dass moderne CPUs keine Lufter mehr benoti- 
gen. Das ist nicht der richtige Weg. Besser ist es, CPUs so zu ubertak- 
ten, dass sie eine Wasserkuhlung benotigen, weil diese Leckschlagen 
kann und man dann weitere Schwierigkeiten zu losen hat. 

Wurde man die Plardware auf leistungsfahige Stackmachinen 
aufrusten braucht man auch keine Kuhlung. Die Systeme wurde 
gerauschlos arbeiten und sie waren supereinfach zu programmieren. 
Will das jemand ernsthaft? Wohl kaum, die Welt ware langweiliger 
wenn es zuviel Perfektion gibt. 

11.3 Fixed Gear Fahrrader haben keine Bremsen 

In der Welt der Informatik ist Forth einmalig. Keine andere Program- 
miersprache spaltet so sehr die Gemuter. Woran das liegt lasst sich 
leicht sagen. Bei Forth fehlt etwas. 1 auf Seite 3 war das Eingangsbe- 
sipiel mit dem “Hello World Sourcecode” in Forth. Wenn man sich den 
Code nochmal anschaut sind es die fehlenden Klammern, genauer 
gesagt die Parameterubergabe, die die Sache so luftig erscheinen 
lassen. Irgendwie ist das ungewohnlich und cool gleichermaBen. Zu- 
mindest auBerhalb der Informatik gibt es etwas vergleichbares. So- 
genannte Fixed Gear Fahrrader, besser bekannt als Bahnrad, sind 
gleichermaBen wie faszierend wie gefahrlich. Auch dort fehlt eine 
wichtige Eigenschaft: die Bremsen, es gibt ubrigens auch keinen 
Freilauf, sondern das Rad ist direkt mit der Kette verbunden. Fixed 
Gear Fahrrader wurden erfunden urn das Fahrradfahren lernen zu er- 
leichtern. Genauer gesagt haben sie das Ziel eine einheitliche Trit- 
tfrequenz zu ermoglichen. Es wirkt, als wenn Mensch und Maschine 
miteinander verschmelzen. Ungefahr so kann man auch Forth ein- 
stufen. Forth wurde erfunden, urn das Programmieren zu erlernen. 
Gleichzeitig sind Forth bzw. Fixies fur den StraBenverkehr nicht zuge- 
lassen. Das ganze ist nicht nur ein Frage der Technik sondern aucn 
der Kultur. Fixies sind genauso wie Forth Teil der Counterculture. Also 
einer Stromung welche sich zu dem Thema als Pro positioniert und 
dadurch die Mainstream Gesellschaft ablehnt. 

Warum Fixies fur den StraBenverkehr nicht zugelassen sind ist 
simpel. Wenn man damit einen Berg herunterfahrt und versucht 
zu skidden (also das Hinterrad ausbrechen lasst) besteht eine 
hohe Unfallwahrscheinlichkeit. Damit gefahrdet man sich und an¬ 
dere Verkehrsteilnehmer. Warum Stackmachinen in der Mainstream- 
Literatur nicht Oder sehr abfallig beurteilt werden hat ahnliche Grunde. 
Rein theoretisch kann man sie bauen, aber das gibt mehr Stress als 
es nutzt. 

Wie sieht dieser Stress konkret aus? Nun, wenn man Program¬ 
mieren lernen mochte, geht es nicht nur urn den Computer an sich, 
sondern auch urn die Kultur dahinter. Das was der Mainstream als ko- 
rrekten Umgang mit Computern einschatzt ist die UNIX Culture, wo 
man also mit einer Plochsprache wie C ein Betriebssystem schreibt 
und darauf aufbauend dann Erweiterungen geschrieben werden. Es 
geht darum, diese Kultur zu verinnerlichen. Wenn man hingegen Forth 
lernt, wird man Teil einer anderen Bewegung. Der Forth Kultur, diese 
ist inkompatibel zu UNIX wie auch C gleichermaBen. Und wo immer 
Forth Experten auf Unix Experten stoBen gibt es Streit. 

Jetzt kann man sagen, hey Leute so schlimm ist das nicht, es sind 
doch nur Computer. Doch damit wird man der Sache nicht gerecht. 
Auch Fixies haben mit normalen Fahrradern keine Gemeinsamkeit, 
vielmehr ist der Kontrast so gewollt. Forth ist nicht kompitbel mit C. 
Und wird es auch nie sein. Forth ist bose. 

Urn es klar zu sagen, Forth hat mit Informatik nicht viel zu tun. Es 
geht eher urn eine Lebenseinstellung, also das Bejahen von etwas 
was wichtig ist. Forth grenzt sich nicht bewusst vom Mainstream ab, 
sondern es war schon immer anders. 

Schauen wir nochmal auf das Fixed Gear Fahrrad. Kann man so 
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nicht herumfahren, wo ist das Problem? Das Problem ist, dass das 
Fahrrad keinen Freilauf besitzt, wenn man die FuGe von den Ped- 
alen nimmt, drehsn sie sich weiter. Das Problem mit Forth ist so ahn- 
lich. Es hat keine Register. Dadurch ist es ncht mdglich, effiziente 
Hochsprachencompiler dafOr zu schreiben. Und ohne Compiler auch 
keine Betriebssysteme. Generell geht es also urn die Frage, wieviel 
Minimalismus moglich ist. 

Vielleicht dazu ein konkretes Beispiel: Angenommen man hat eine 
8080 CPU vorliegen und mochte dafur einen C Compiler schreiben. 
Man wird feststellen, dass die CPU arg wenig Register besitzt und 
es deshalb nichts wird mit dem Compiler. Jetzt gibt es zwei Mogliche 
Antworten. Entweder erhoht man die Registerzahl urn dann leichter 
einen C-Compiler programmieren zu konnen. Oder man lasst die Reg¬ 
ister so wie sie sind und geht sogar noch mehr in Richtung Minimal 
Instruction Set so dass man uberhaupt keine Hochsprachencompiler 
mehr entwickeln kann. Letzteres wird als Forth-Style bezeichnet. 

Selbst mit heutiger Technik ist es nicht moglich fur einen Minimal In¬ 
struction Set Computer effiziente Hochsprachencompiler zu program¬ 
mieren. Das passt irgendwie nicht zusammen. Der Mainstream hat auf 
das Problem derart reagiert, dass er Software wichtiger als Hardware 
bewertet. Das heiBt, Intel baut einfach jene Prozessoren fur die es C- 
Compiler gibt und macht genau das, was die Softwareentwickler wun- 
schen. Wahrend man bei Forth den umgekehrten Weg eingeschlagen 
hat und die Bedurfnisse von C Programmierern konsequent ignoriert 
und stattdessen ein Umdenken beim Erstellen der Programme fordert. 
Das man also in Konzepten einer Stackmachine denken soil und nicht 
wie bei C auf den Code fokussiert. 

Gewonnen hat bei diesem Spiel Forth, naturlich. Forth steht heute 
besser da denn je. Die Community ist besser aufgestellt, die Prozes¬ 
soren sind leistungsfahig und der Vorsprung gegenuber Intel gewaltig. 
Der Verlierer hingegen ist der Mainstream. Er kampft mit hohen Fer- 
tiungskosten, Abwarme durch die Prozessoren und fehlenden Stan¬ 
dards. 


Ohne Betriebssystem Die wichtigste Eigenschaft von Forth-CPUs 
ist, dass es dafOr kein Betriebssystem gibt. Das ist jedoch kein Man¬ 
gel, sondern ist der Auslbser fur verschiedene Workarounds. Die Kul- 
tur in der Forth Community basiert darauf, uber Gegenstrategien zu 
beraten wie man auch ohne Hochsprachencompiler und ohne Be¬ 
triebssystem auf einem Chip rechnen kann. Die Antworten darauf 
sind vielfaltig. Mit einer Ausnahme. Die Antwortet lautet nicht, die An- 
zahl der CPU Register zu erhohen, so dass man einen C-Compiler 
auf die Plattform portieren kann. Dann ware es kein Forth System 
mehr sondern etwas anderes. Ungefahr so ahnlich ist auch die Men- 
talitat auf einer Skidding Veranstaltung. Anstatt einfach das Fahrrad 
aufzubocken und den Freilauf nachzurusten hat man sportliche Meth- 
oden entwickelt wie man das Fahrrad anders abbremst als es nor- 
malerweise ublich ist. Die interessantesten / gewagtesten Mannover 
werden beklatscht. Wenn das Skidding jedoch miGlingt, schrammt 
man mit dem Ellenbogen auf dem Asphalt entlang. Wenn man es auf 
einem Forth Treffen nicht schafft ohne Betriebssystem auszukommen, 
passiert nach dem Einschalten gar nichts. Das heiBt, die CPU bootet 
nicht, es ist kein Bild zu sehen. Wenn man n icht weiG wie das geht 
mit Forth kann man daran auch nichts andern. 

Die Fixie Biker spielen mit dem Risiko einen Unfall zu bauen, als 
Forth User spielt man damit den Computer nicht sinnvoll einsetzen zu 
konnen. Das wird komischerweise als Befreiung verstanden. Ja einige 
Zuschauer applaudieren sogar explizit bei solchen Fail-Situationen. 
Also wenn jemand einen Forth Chip mitbringt ohne die passende Soft¬ 
ware liefern zu konnen. “Bravo” heiBt es dazu aus dem Publikum. Und 
“Zeig mal her, das will ich auch haben”. 


Damenfahrrader Vielleicht sollte an dieser Stelle einmal 
beschrieben werden, wie ein bequemes und alltagstaugliches 
Fahrrad aussieht. Zunachst einmal besitzt es einen Freilauf, was 
bedeutet, dass man aufhoren kann mit dem Treten und das Fahrrad 
weiterrollt. Weiterhin befindet sich am hinteren Rad ein Rockschutz 
wodurch man auch in Alltagskleidung fahren kann und ganz wichtig, 
es gibt eine Vorder- und eine Hinterbremse, so dass man auch ohne 
einen Skid-Stop anhalten kann. Zu guter letzt sind helle Beleuch- 
tungen vorne und hinten ein sinnvolles Accessoire sowie ein Korb 
in dem man Lebensmittel verstauen kann. Auch ein Kettenschutz, 
ein Fahrradstander sowie eine am Lenker angebrachte Klingel sind 
empfehlenswert. So und nicht anders sieht ein StraBentaugliches 
Fahrrad aus, mit dem man gemutlich und unter Beachtung der 
Verkehrsegein uber die Fahrradwege von New York City fahren kann. 
An einer roten Ampel halt man vorschriftsgemaB an und wenn man 
die Seite wechselt zeigt man dies an, damit der nachfolgende Verkehr 
sich darauf einstellen kann. 

11.4 Forth bloBstellen 

Eigentlich ist Forth eine sehr schone und machtige Programmier- 
sprache. Wenn man sich fur Computersprachen interessiert wird man 
vielleicht zur der Erkenntnis gelangen, dass Forth die beste Sprache 
ist die jemals erfunden wurde. Insbesondere wenn man in Forth einen 
rekursiven Algorithmus aufstellt der eine Turtle Grafik zeichnet wird 
man von seiner Einfachheit und Eleganz beeindruckt sein. Bei Forth 
gibt es aber auch etwas, was nicht so gut funktioniert. Und zwar das 
Veranstalten von Wettbewerben. 

Eigentlich ist das etwas was alltaglich ist in der Informatik. Man 
denkt sich eine Aufgabe aus, und verschiedene Teams mussen dann 
in vorgegebener Zeit eine Losung finden, am Ende wird ein Sieger 
gekuhrt. Es gibt solche Wettbewerbe urn in einer 1 Stunde computer- 
spiele zu programmieren Oder urn Roboter auf einer Linie langfahren 
zu lassen. Komischerweise ist sind die Hardcoresprachen Forth, APL 
und Lisp jedoch weitestgehend Challange-Freie Zonen. Es gibt keine 
Oder nur sehr zaghafte Bestrebungen in diese Richtung. 

Wenn man einen typischen Vortrag zu Forth iauscht wird man ir- 
gendwann zu der zynischen Erkenntnis gelangen, dass Forth eine 
sinnlose Sprache ist. Ich meine, wozu braucht man ein Word. Hau- 
fig wird dann der Sinn damit erklart, dass man damit weitere Worter 
definieren kann, doch das ist eine Erklarung innerhalb des Forth Ide¬ 
ologic. Und schnell stellt sich bei Einsteigern der Verdacht auf, dass 
sie niemals werden Forth verstehen. Mit Forth hat das jedoch nichts 
zu tun, sondern mit einer Unterrichtssituation ohne Fokussierung auf 
Anwendung. Generell besteht guter Unterricht aus zwei Teilen: ein¬ 
mal die vermittlung von theoretischen Grundlagen, ohne die es nicht 
funktioniert und anschlieGend dann der praktische Teil wo es urn die 
Anwendung geht. Bei Forth wird meistens auf den 2. Teil verzichtet. 
Das ist schade, aber man kann es andern. 

Wenn man Forth, APL Oder Haskel in einer Challange einsetzt, er- 
weitert man die Aufgabenstellung. Es geht nicht langer urn Wissen 
was der Lehrer hat und wo man selber nur zuhoren kann, sondern in 
einer Challange geht es gar nicht primar urn die Sprache sondern urn 
ein soziales Spiel. Wer schafft es, das beste Programm zu schreiben, 
wer hat die kreativste Losung. 

Bei dezidzierten APL und Forth Wettbewerben kann man einen in- 
teressante Aspekt beobachten. Und zwar verschieben sich die Prob- 
lemldsungsstrategien in Richtung Mainstream. Normalerweise wird 
APL in den Lehrbuchern als Listenverarbeitende funktionale Sprache 
mit einer sehr sondernbaren Syntax dargestellt. Will man jedoch mit 
APL ein Spiel unter Wettbewerbssituationen programmieren wird im 
Regelfall nicht das reine APL eingesetzt, sondern eines was urn objek- 
torientierte Features erweitert wurde. Das heiBt, APL wird zwangslau- 
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fig in Richtung Java umfunktioniert. Und exakt das passiert auch 
mit Forth. Will man mit Forth in einem Wettbewerb gewinnen, wird 
man ebenfalls vorher den Interpreter urn OOP Features aufrusten 
und einen programmierstil verwenden der eher nach C++ als nach 
Forth aussieht. Und zwar, weil die theoretischen und praktischen An- 
forderungen sich unterscheiden. 

Versuchen wir einmal etwas naher einzutauchen in “Forth program¬ 
ming challanges”. Es ist erstaunlich schwer konkrete Beispiele zu find- 
en. Als erstes gefunden habe ich den “Forth Benchmark Wettbewerb”. 
Es handelt sich dabei um ein Forth Programm, was man auf unter- 
scheidlichen Vintage Computern wie Atari ST und C-64 laufen lasst 
und was die Performance ermittelt. Aber, das ist kein Progrmamier- 
wettbewerb, sondern die Challange wird zwischen den Computern 
ausgetragen. Dort gewinnt beispielsweise der C-64 weil er am schnell- 
sten die Primzahlen ermittelt hat. Ein Programmierwettbewerb wird 
jedoch zwischen Menschen veranstaltat, wo man also 4 Stunden Zeit 
hat um Code zu schreiben. 

Im Usenet unter “comp.lang.forth” gibt es ebenfalls keine Berichte 
uber durchgefuhrte Forth Challanges. Das einzige was ungefahr in 
diese Richtung geht, war eine Diskussion uber den Forth Day 2003, 
dort wurde abschweifend diskutiert, ob man nicht eine programmier 
Challange durchfuhren sollte. Das wurde abgelehnt: 


anders als Forth sehr viel Speicher, lasst sich nicht effizient threaden 
und rekursion ist verpont. Insofern dienen Wettbewerbe dazu, dieses 
Manko auszugleichen. 

Besonders in Europa sind Programmierwettbewerbe in Anfanger- 
sprachen wie Java und C sehr beliebt. Weil man gegenuber den USA 
sehr viel aufzuholen hat und das eine Moglichkeit ist, das auf unter- 
haltsame Weise zu tun. 

Micromouse Mit etwas suchen habe ich doch noch einen dezi- 
dierten Forth Programmierwettbewerb gefunden. Jedenfalls fast. In 
der Micromouse Challange mussen winzig kleine Microcontroller pro- 
grammiert werden, auf denen ublicherweise Forth vorinstalliert ist. 
Auch die Vierte Dimension berichtet regelamaBig uber diesen Wet¬ 
tbewerb. Micromouse ist eine der seltenen Gelegenheiten wo die 
Programmiersprache Forth unter Wettbewerbsbedinungen verwendet 
wird. 

Aber, Micromouse ist kein dezidierter Forth Wettbewerb, und trotz 
intensiver Google Suche habe ich kein einziges Sourcecodebeispiel 
finden konnen. Ublicherweise wird dort C Oder Assembler eingesetzt 
um die Roboter ins Ziel zu bringen. micromouse "forth programming" 
Von einem Teilnehmer Duncan Louttit gab es wohl mal einen Vortrag 
auf einer Forth Konferenz, den Sourcecode zu seinem Maze solver 


“Now this kind of real world programming challange would wiN er uns aber nicht verraten. Es ist also tasachlich so, dass Forth 

emphasis just how different this kind of programming is und Coding-Challanges nicht zueinander finden. 

from the sort of programming that many people do regu- Das is* inhaltlich technisch sehr ungewohnlich, weil Forth sich 

larly. Suddenly a trivial Hello World program does not look eigentlich ausgezeichnet eignet um Microcontroller zu program- 

quite so trivial. ” 17 mieren. Und auf Forth Tagungen sind Microcontroller regelmaBig ein 

Thema. Und mehr noch, es gibt in der Forth Community auch sehr 
Hat die Forth Community womoglich Angst vor einer Programmier- vie|e Paper die sjch mit Robotics beschaftigen. Ich glaube, das Prob- 

challange? Schaut man sich einmal an, wie der Forth Day 2003 | em was besteht ist nicht so sehr die technische Seite, sondern dass 
und alle nachfolgenden Treffen durchgefuhrt werden, so gibt es dort die Forth Leute irgendwie zu Programmierwettbewerben auf Abstand 
Prasentationen, leckere Verpflegung, Microcontroller zum Anfassen gehen . WQrde es nicht um einen Ro boterwettbewerb sondern um eine 
und sehr neue LED Beamer, aber es gibt keine Programming Chal- Coding-Challange fur Natural Language gehen, wurde sich Forth ver- 
langes. Das ist doch ein wenig merkwurdig Oder? Sollte ausgerech- mutNch ebenfa ,| s sehr zurQc khaltend zeigen, obwohl auch hier eine 
net die machtige Sprache Forth ungeeignet sein um darin Program- , ange Tradition in Bezug auf Forth und Natura , Langua g e Processing 
mierwettbewerbe zu veranstalten? Wohl eher nicht. Forth ist turing- bes t eb t 
machtig und man kann darin ausgezeichnet programmieren. 

Der Begriff “Programming Challange” wird in der Forth Communi¬ 
ty in einem semantisch anderen Kontext verwendet. Als Challange "I "I-5 Einsatzszenarien von Forth 

wird ublicherweise in einem Text eine Herausforderung bezeichnet. So Forth hgt a|s Vortei| gegenQber Linux sehr viel minima |ii sch er zu sein 
wird in der Einleitung ein Primzahlalgorithmus als Challange bezeich- ynd a|g Nachtei|> dass es schwer ist in Forth zu programmi eren. Den 
net um dann im weiteren Verlauf das dazugehbrige Forth Programm MinimaNsmus von Forth kann man produktiv einS etzen, wenn man 
zu entwickeln. Soweit ist das auch in Ordnung, aber Challange heiBt sehr k|eine Microcontro || er prog rammieren mbchte. Also Systeme wo 
mehr als einfach nur ein Beispiel zu bringen, eine Challange ist ein kejn Linux Kerne| draufpasst . Aber Forth eignet sich auch gut , wenn 

sportlicher Wettbewerb der wirklich durchgefuhrt wird und nicht nur mgn organische Computer pr0 grammieren will. Nanoroboter die aus 
eine literarische Figur um einen didaktischen Text aufzulockern. molekulen gefertigt sind, bringen ebenfalls nur wenig CPU Leistung 

und wenig RAM auf die Wage. Theoretisch kann man darauf auch die 
C Programming Challange Technisch gesehen geben ich der Forth Programmiersprache Brainfuck ausfuhren, Brainfuck hat jedoch den 
Community recht, wenn sie C als schlechte Programmiersprache Nachteil ein wenig zu minimalistisch zu sein. In Brainfuck selber Code 
bezeichnet. Es ist nicht besonders schwer darin zu programmieren, zu schreiben ist schwer. Langjahrige C Programmierer werden ein- 
Forth ist weitaus interessanter und tiefgrundiger. Aber, rund um die C- wenden dass man ja auch C einsetzen kann und uber einen compiler 
Community haben sich Programmierwettbewerbe etablieren konnen, daraus Assembler Code erzeugen konne. Nur, erstens benotigt man 
diese sind fast noch wichtiger als die eigentliche Sprache. Diese Wet- dafur einen Crossassembler und zweitens ist der generierte Assem- 
tbewerbe dienen dazu, in einen sportlichen Wettstreit zu treten und b | e rcode nicht wirklich minimalistisch. Wenn genuugend CPU Leis- 
verlieren zu lernen. Das fehlt ein wenig in der Forth Community. Die tung bereitsteht wie auf einem Raspberry PI Computer ist das kein 
Technologie die sie verwenden ist besser, aber es fehlt die soziale Problem, aber wenn nicht bleibt eigentlich nur Forth als Moglichkeit. 
Einbettung. Ja fast hat man den Eindruck, als ob das so gewollt ware, Kommen wir zu einem Grund der gegen Forth spricht. Und zwar 
dass man mit forth nichts sinnvolles anfangen kann und vor allem dass gi | t die Programmierung als schwierig. Es ist schwerer in Forth ein 
man in einem Programmierwettbewerb keine Preise gewinnen kann. p rog ramm zu erstellen als in C und vor allem gibt es fur Forth keine 
Warum man fur die Sprache C Programming Challanges veranstal- gu te Bibliotheken. Will man etwas programmieren muss man das Rad 
tet ist simpel: weil die Sprache selber nichts zu bieten hat. Sie benotigt nochmal neu erfinden. Desweiteren ist der Umgang mit dem Stack 

17 https://groups.google.com/forum/SIsearchin/comp.lang.forth/challangelsort+elevance/telflJiPi^j^fifthfefe^SSfl;-®^® Simplen Primzahlalgorithmus in Forth fer- 
OM/pqr5d8bDVFsJ tiggestallt hat vergehen viele Stunden. Aber, in der Praxis ist der 
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Aufwand vernachlassigbar. Und zwar weil man Forth nicht verwen- 
det um darin Algoirthmen zu erfinden Oder sich auszudenken wie 
man generell einen Roboter programmiert sondern Forth ist eine Ziel- 
sprache wenn man den Algorithmic bereits in Python vorliegen hat 
und ihn lediglich auf einem Microcontroller ausfuhren mochte. Ein 
idealer Workflow mit Forth-in-the-loop sieht so aus, dass man als 
Python Programm einen leistungsfahigen RRT Pfadplanner program¬ 
miert und optimiert hat, diesen ausdruckt und den Code manuell fur 
Forth umschreibt. 

Forth steht selbstverstandlich in Konkurrenz zu anderen Program- 
miersprachen. Ein heiBer Anwarter Forth vom Socken zu stoBen 
ist das erwahnte Python. Mit Micropython gibt es eine Distribution 
welche auf Microcontrollern lauft, wo man also 1:1 den Code der auf 
dem Desktop lauft ubertragen kann und uberhaupt nichts mehr um- 
schreiben muss. Aber, Micropyhton stellt im Vergleich zu Forth relativ 
groBe Anforderungen an die CPU. Weiterhin ist von Python bekannt 
dass die Echtzeitfahigketten und Multitasking-Eigenschaften nicht die 
besten sind. Und minimalistisch ist Python ganz sicher nicht. Es ist 
vergleichbar, als wurde man C# auf einem Microcontroller ausfuhren. 
Es geht zwar auch, aber es ist nicht sehr nahe an der Flardware. 

Ein weiterer Vorteil von Forth ist, dass man kein seperates Betrieb- 
ssystem benotigt. Forth bringt sein eigenes BIOS mit, seinen eigenen 
Kernel und seinen eigenen Editor. Eine Sprache die noch schlanker 
ist, gibt es nicht. Forth ist gewissermaBen die unterste Ebene. 

11.6 Auf Forth verzichten 

Forth definiert sich selbst als minimalistische Programmierumgebung. 
Und bis heute kann kein C-Compiler oder linux-artiges Betriebssys- 
tem es in dieser Hinsicht mit Forth aufnehmen. Aber ist deshalb Forth 
unersetzlich? Wahrer Minimalismus beginnt dort wo man auf Forth 
verzichtet, also auf einen Minimalismus nicht angewiesen ist und sich 
stattdessen einen 32 bit ARM Microcontroller kauft, dort Micropython 
installiert und dann schon ineffizient seinen Micromouse Roboter ins 
Ziel bringt. Der Clou ist dass der Verzicht auf Forth keine Nachteile 
mit sich bringt. Dadurch wird der Roboter keineswegs langsamer. Der 
eigenliche Flaschenhals bei Micromouse ist nicht die Frage ob nun 10 
kb oder 2000 kb an RAM Benotigt werden sondern der Flaschenhals 
ist eher in der High-Level-Programmierung zu suchen, also welche 
Algorithmen verwendet wurden. 

Richtig ist, dass wenn man Forth verwendet man damit seine 
schone Roboter bauen kann. Aber Forth ist keine Grundfertigkeit die 
man haben muss weil alternativ das komplette Projekt scheitert. Son¬ 
dern Forth ist eher ein luxorioses Addon. Flat man kein Forth ist 
das kein Nachteil. Was jedoch ein Nachteil ist und hier beginnt der 
wirkliche Minimalismus, ist wenn man keine Ahnung von UML Dia- 
grammen und Objektorientierter Programmierung in Python besitzt. 
Weil ohne das, man kaum wird eine leistungsfahige Robot-Control- 
Software wird entwickeln konnen. Nur mit Forth oder C ist es nicht 
moglich sowas zu tun. 

Minimalismus ist laut Definition das Weglassen von uberflussigem 
Beiwerk. Objektorientierte UML Diagramme kann man nicht we¬ 
glassen, und das git Versionsverwaltungssystem auch nicht, weil 
sonst das komplette Projekt scheitern wurde. Worauf man jedoch 
verzichten kann ist es, sich in Forth einzuarbeiten und die Pro¬ 
grammierung eines Stacks zu verstehen. Diese Fahigkeiten sind ent- 
behrlich, es gibt gute Alternativen dazu. 

Es mag ein wenig sonderbar klingen wenn man eine minimalistis¬ 
che Forth Umgebung als Luxus bezeichnet, aber so ist es. Den Min¬ 
imalismus von Forth muss man sich leisten konnen. Genauer gesagt 
geht es darum, Dinge zu verwenden die durch etwas anderes erset- 
zt werden konnen ohne die Funktion zu beeintrachtigen. Einen Forth 
Microcontroller kann man leicht gegen ein C-Microcontroller oder ein 


Python Aquivalent austauschen. Und ein Stackprozessor lasst sich 
durch groBere Modelle die mehr Geld kosten ersetzen. Die Frage ist 
naturlich warum man das tun sollte. Der einfachste Fall ist einfach 
Zufall. Das heiBt, wenn irgendwann der Forth Microcontroller kaputt 
geht und kein anderer da ist, dann nimmt man eben einen wo Lin¬ 
ux vorinstalliert ist. Das ist zwar nicht so klein und schlank aber zur 
Not geht es auch. Ich will nicht behaupten es gerne zu sehen, wenn 
Forth ins Abseits gedrangt wird, das Problem ist nur dass Forth keine 
Qualitaten mitbringt die nicht auch andere besitzen. 

Rein vom technischen her stellt Forth das Optimum in Sachen 
Microcontrollerprogrammierung. Kein anderes System ist so stroms- 
parend so leicht zu installieren und so effizient wie ein eForth Sys¬ 
tem. Aber man sollte nicht vergessen, dass Microcontroller nur Mit- 
tel zum Zweck sind, sie dienen dazu eine Aufgabe zu erledigen und 
man ist nicht abhangig von Forth. Wovon man hingegen abhangig ist, 
dass ist Softwareentwicklung und zwar insbesondere solche bei de- 
nen groBere Projekte das Ziel sind. Wer nicht in der Lage ist komplexe 
Systeme zu entwerfen und zu debuggen, dem nutzt der beste Micro¬ 
controller gar nichts. Er kann zwar hubsch die Lampen blinken lassen, 
aber das reicht nicht aus. 

11.7 Python vs. Forth 

Warum die Leute Python einsetzen und nicht C ist simpel. Zwar 
ist die Sprache C besser auf Microcontroller abgestimmt aber es 
ist aufwendig, in C ein WLAN Modul anzusteuern, einen Webserver 
aufzusetzen oder Live-Daten zu visualisieren. Anders gesagt, Micro- 
phyton ist das worauf die Welt gewartet hat. Und noch mehr, genau- 
so gibt es zahlreiche Griinde warum die Leute lieber Python anstatt 
mit Forth ihr Gluck zu versuchen. Es sind die selben Grunde und 
noch einige mehr. Ein Forth System lasst sich zwar auf jeden Mi¬ 
crocontroller installieren aber etwas damit anfangen kann man nicht. 
Will man einen Pfadplanner programmieren muss man sich erstmal in 
die Arrayprogramming in Forth vertiefen. Da ist aufwendig. Will man 
einen Webserver aufsetzen muss man ebenfalls manuell program¬ 
mieren. Flat man hingegen Micropython reicht ein simpler Befehl und 
der Server ist online. Genau genommen konnen sich Python User al¬ 
so den Minimalismus von Forth nicht leisten. Der Witz ist, dass ein 
groBerer Microcontroller mit mehr Speicher effektiv billiger kommt als 
wenn man einen Forth Microcontroller verwendet. Warum? Weil bei 
Micropython alles out-of-the-box mit dabei ist. Man kann damit zugiger 
ein Projekt durchfuhren und kommt schnellerzu Resultaten. 

Wenn man von Forth auf C wechselt ist das fur einige Offen- 
barhung. Plotzlich kann man in der FHalfte der Zeit die doppelte Menge 
an Code schreiben. Man muss sich nicht zweimal uberlegen wie das 
mit dem Stack geht sondern schreibt einfach hin was man machen 
will. Noch viel angenehmer ist der Umstieg von C auf Python. Dort 
ist die Programmierung noch leichter, und das Debuggen geht noch 
schneller. 

11.8 Transcompiler, Konverter und Compiler zu 
Forth 

Das man Forth nativ programmieren kann ist bekannt. Leider ist das 
Erstellen von dezidiertem Forth Code sehr schwer. Umso nutzlicher 
wenn man Konverter hat die in die Forth Sprache automatisch uber- 
setzen. Die Auswahl solcher Konverter ist nicht sehr hoch, aber es gibt 
sie: 

• C to Forth: https://github.com/dmedinag/C-to-Forth-compiler 
basiert auf einer Bison-Datei um den Parsergenerator zu erzeu- 
gen. Damit kann dann eine “.c” Datei in eine “.fs” Datei kon- 
vertiert werden. 


31 



• Bramfuck to forth: https://github.com/kmyk/forth-to-brainfuck medergeschriebenen Betriebssystembibliotheken nutzt wird die Aus- 

ausprobiert habe ich diesen Konverter noch nicht. Laut Beshrei- breitung von Wissen verhindert. Es entsteht eine stark hierarchiche 
bung soil er die esoterische Programmiersprache Brainfuck in Gesellschaft bei der einige wenige uber die Interna eines Comput- 
Forth Code ubersetzen konnen. ers informiert sind und dieses Wissen fur sich behalten. Das ist die 

Essenz von Forth. Sage nichts, schreibe nichts auf, behalte dein Wis- 

• Scheme to Forth: http://www.complang.tuwien.ac.at/schani/oldstuff^plfig|rT^tfffP l S l a lautet das Mantra. Wo man keinen Sourcecode als 


Scheme ist ein Lisp Dialekt der ahnlich wie Forth einen Metapro- 
grammieransatz verfolgt. Leider ist unklar wie das Programm 
aufgerufen wird, ich konnte es nicht testen. 

11.9 Ein Betriebssystem fur Forth 

Eine Programmiersprache wie Forth ist sinnlos wenn man kein Be¬ 
triebssystem dazu hat. Leider ist zu diesem Thema die vorhandene 
Literatur sehr durftig. Genannt werden folgende Betriebssysteme die 
in Forth geschrieben sind: 

• ForthOS (unabhangige Entwicklung, komplett ohne Dokumenta- 
tion) 

• 4os (war auf dem iTV Forth PC vorinstalliert) 

• bigforth (Anleitung auf Deutsch vorhanden, wurde ursprunglich 
fur den Atari ST entwickelt und besitzt ein objekorientiertes Fen- 
stersystem) 

Nach etwas Suchen bin ich noch auf einen Begriff gestoGen, der rele¬ 
vant sein durfte: OSkit. Ausgeschrieben heiBt es “Flux OS Toolkit” [4], 
Gemeint ist eine Sammiung von sehr allgemein gehaltenen Routinen 
mit denen man ein Betriebssystem automatisch generieren kann. In 
welcher Programmiersprache OSkit entwickelt wird ist unklar. In der 
Theorie kann man damit auf Knopfdruck ein beliebiges Betriebssys¬ 
tem erzeugen und spart sich das was Linus Torvalds als Kernel De¬ 
velopment bezeichnet. 

Die Vermutung liegt nahe, dass auch ForthOS und 4os mithilfe von 
OSkit erzeugt wurden. Also keineswegs dajemand 50 MB an Source- 
code in der Sprache Forth eingetippt und gedebuggt hat, sondern die 
Software aus dem Generator kam. Die Idee geht ungefahr so: Zuerst 
portiert man ein Forth System auf eine neue Plattform, wie z.B. x86. 
Dann nimmt man eine kleine Zusatzdatei die nicht groGer ist als 2 
kb urn aus dem Forth System einen Scheme Interpreter zu machen. 
Dann lasst man darin das OSkit laufen und erzeugt den Code fur einen 
Kernel, dann wird auf ahnliche Weise ein Lisp kompatibler Window 
Manager erzeugt und so kann man das komplette Betriebssystem inkl. 
Spiele und TCP/IP aus sehr wenigen zeilen Code erzeugen. Metapro¬ 
gramming heiBt das in der Fachsprache. Also Programmieren ohne zu 
programmieren. Ob sich das ganze wirklich realisieren lasst ist unklar, 
reine Spekualtion das ganze. 

11.10 Schriftkultur 

In einer Schriftkultur werden Informationen in Biichern notiert. Mit 
den Informationen hat das zunachst nichts zu tun, sondern mit 
dessen gesellschaftlicher Bedeutung. Man kann auch in einer nicht- 
schriftlichen Gesellschaft ein hervorragender Arzt sein, das Wis¬ 
sen uber Anatomie ist das selbe. Der Fokus liegt also auf Kultur, 
und meint wie Arbeit geteilt wird und wie Wissen organisiert wird. 
Schauen wir uns jetzt einmal die Forth Communit und ihrem Streben 
nach Sourceless Development an. Es bedeutet dass man auf eine 
Schriftkultur verzichtet. Genauer gesagt verzichtet man auf das Er- 
stellen von Libraries. Uber das Programieren oder Informatik sagt das 
allein nichts aus, sondern Forth kann man eher als Gesellschaftsbild 
bezeichnen. Also wie die Arbeit verteilt wird und der Zugang zu In¬ 
formationen geregelt ist. Wenn man keine Bucher und keine formal 


Bibliothek aufschreibt und wo man keine Bucher uber Compilerbau 
publiziert gibt es auch keine Gegenseite die diese lesen kann. Man 
bleibt unter sich, schottet sich ab, grenzt sich ab.Forth mit dem Mit- 
telalter zu vergleichen ist so falsch nicht. Auch im Mittelalter war das 
Wissen auf die Kaste der Monche beschrankt, sie waren die einzi- 
gen welche Latein konnten. AuBenstehende erhielten keinen Zugang. 
Technisch gesehen mag das funktionieren. Im Mittelalter hat man sehr 
gutes Latein gesprochen. Ob Wissensmonopole jedoch gut sind wenn 
man Mitbestimmung, Aufklarung und freies Denken fordern mochte ist 
fraglich. 

Forth funktioniert auf eine simple Weise. Man verteuert die Ware 
Information und erschwert dadurch den Zugang. Wenn es keine Be¬ 
triebssysteme gibt, kann man auch nicht davon lernen, wenn es 
keine Bucher gibt, kann man die Sprache nicht lernen. Forth ist eine 
Form des gesteigerten ClosedSource, wo also nicht der Quellcode a) 
geheim ist und b) gar nicht ais Quellcode niedergeschrieben wird. Das 
man damit Informatik betreiben kann, demonstriert die Forth Com¬ 
munity eindrucksvoll. Auf den Treffen werden immer mal wieder Al- 
gorithmen vorgestellt die etwas sinnvolles tun. Wie man zu diesen 
Algorthmen kommt ist unklar, vermutlich durch mundliche Uberliefer- 
ung. Vielleicht gibt es auch irgendwo Aufzeichnungen daruber die je¬ 
doch nicht so offensichtlich sind. Die Grundhaltung ist jedoch restrik- 
tiv ausgelegt. Forth bedeutet informatik zu betreiben ohne daruber 
zu publizieren und ohne den Sourcecode aufzuschreiben. Das heiBt, 
man betrachtet das Wissen uber Computer als zu wertvoll urn es 
mit der Welt zu teilen sondern schreibt es wie Leonardo da Vinci 
in Spiegelschrift auf oder noch besser, hinterlasst keinerlei Notizen. 
Damit vermeidet man, dass das Wissen in Falsche Hande gelangt. 
So ahnlich wie in dem Film “Der Name der Rose" als der halbblinde 
Monch ein wichtiges Buch versteckt hat. 

Und hier wird auch deutlich warum die Forth Community so abfal- 
lig uber UNIX und die C-Programmiersprache urteilt. Weil UNIX da- 
rauf ausgelegt ist, Informationen zu teilen. Also nach der Hacker- 
Mentalitat Sourcecode auf Tape uberall hinzusenden, und in Stan- 
dardbuchern alles einsteigerfreundlich aufzubereiten so dass es jeder 
versteht. UNIX und C ist von der Mentalitat her das genaue Gegen- 
teil von Forth. Die einen Teilen Wissen, die anderen behalten es fur 
sich. Die einen schreiben es in Buchern und als Quelltext nieder, die 
anderen Idschen den Code wieder nachdem der Computer den Task 
ausgefuhrt hat. Die einen wollen mit dem Computer die Welt veran- 
dern die anderen wollen zuruck ins Mittelalter. 

Forth ist keine Programmiersprache oder Programmiersystem, 
Forth ist der Gegenentwurf zur Schriftkultur. Es geht nicht darum, An- 
fanger an das Programmieren heranzufuhren oder Betriebssysteme 
mit anderen zu teilen sondern es geht urn Macht. Na ja, vielleicht 
kann man es auch etwas vorsichtiger so formulieren, dass es nur urn 
die Kosten geht. Wenn man den Sourcecode eines Programms nicht 
in einer Datei speichert sondern nur im Kopf herumtragt dann steigen 
die Kosten an. Will jemand anderes das Programm ausfuhren kann er 
die Software nicht einfach bei github herunterladen. Er kommt trotz- 
dem an den Code, muss aber die Gegenseite vorher darum bitten. 
Man kommt trotzdem zum Ziel, nur ist es aufwendiger. 

Die Tendenz informationen fur sich zu behalten ist auch auGerhalb 
von Forth ein weit verbreitetes Argerniss. Der Sourcecode zu Win¬ 
dows 10 steht bis heute nicht auf github und wie ROS im Detail funk¬ 
tioniert, daruber gibt es leider keine Handbucher wo man es nachle- 
sen kann. GewissermaGen ist das Fehlen von Sourcecode und das 
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Fehlen von Handbuchern der Normalfall was man aktiv uberwinden 
muss urn die Dinge voranzubringen. Geschichtlich gesehen stellt die 
Erfindung von OpenSource eine Zasur da. Nicht weil plotzlich bessere 
Software bereitstand sondern weil Software als Medium verstanden 
wurde, was ahnlich wie das Fernsehen in jeden Flaushalt ubertragen 
wird. 

Von diesem Ideal ist die Forth Community meilen weit entfernt. Es 
gibt noch nichtmal Libraries in Forth die man teilen konnte. Auch Buch¬ 
er wo Forth Programmierung erklart wird sind Mangelware. Ja richtig, 
Forth ist Mangelwirtschaft, es fehlt an allem und das wenige was es 
gibt ist sehr teuer. 

Astrologie Es gibt einen Kontext wo es sinnvoll ist Dinge 
geheimzuhalten. Und zwar wenn man sich selbst als Zauberkiinstler 
versteht wo es zum Berufsethos gehort, keinen Trick zu verraten. Ein 
typisches Forth Projekt konnte in einem Astrologieprogramm beste- 
hen, oder vielleicht auch eine Software zum Gedankenlesen. Ob diese 
Software wiklich etwas sinnvolles tut, oder man nicht einfach nur die 
Gegenseite betrugt sei mal dahingestellt, aber mit Forth geht sowas 
ausgezeichnet. So nach dem Motto: mein Forth Programm sagt mir, 
dass du jetzt mude wirst, dich hinlegst, deine Gedanken werden ruhig. 
Im Bereich des Varietes sind solche Zauberdarbietungen sehr be- 
liebt. Und die Zuschauer erwarten genau diese Form der Darbietung. 
Sie wollen einen richtigen Magier sehen der mit ausholenden Gesten 
die Geister beschwort und ihnen den Untergang verkundet. Auf der 
Weltausstellung 1939 gab es den Roboter Electro zu bestaunen. 
Damals war Forth zwar noch nicht erfunden, aber es ware die ideale 
Sprache gewesen urn den Roboter zu steuern. Und zwar weil Elektro 
wie auch Forth auf maximale Ehrfurcht hin erstellt wurden. Es ging bei 
Elektro darum von oben herab zu predigen. Also modernen Schaman- 
ismus zu betreiben. 

Elektro damals und das heutige Forth darf man nicht als technische 
Errungenschaft interpretieren sondern es handelt sich urn eine Theat- 
erauffuhrung. Das heiBt, Elektro funktioniert nur, wenn es Zuschauer 
gibt, die von seiner gigantischen Stimme eingeschuchtert werden und 
Forth funktioniert nur, wenn jemand es programmieren mochte. Es 
geht nicht wirklich urn Programmieren sondern urn das Setting wie 
Programmieren unterrichtet wird. Am besten kann man Forth in einer 
Schule urn 1900 unterrichten wo es noch die Prugelstrafe gab, nicht 
selbstgesteuertes Lernen war damals angesagt sondern Gehorsam 
dem Lehrkorper gegenuber. Man darf nicht den Fehler machen, Forth 
in Frage stellen zu wollen, weil das eine unangenehme soziale Situa¬ 
tion erzeugt bei dem der Lehrer seine Autoritat durchsetzen wird. Mit 
Forth kommunzieren meint, das soziale Setting zu erkennen in dem 
die Sprache gesprochen wird. 

11.11 1st Forth tot? 

Zwischen Forth und Lisp gibt es groBe Gemeinsamkeiten. Lisp ist eine 
Sprache der kunstlichen Intelligenz, genauer gesagt war es eine. Wer 
sich heute mit LISP beschaftigen mochte, recherchiert im Idealfall in 
Computermuseen. Er findet dort Lisp in Flardware, die alten Fland- 
bucher zu Common Lisp und wird sogar entdecken dass auch die 
DDR Mitte der 1980’er Jahre angefangen hat sich fur LISP zu inter- 
essieren. Ruckblickend war das naturlich reine Utopie. Die Comput¬ 
er der damaligen Zeit waren nicht leistungsfahig genug fur das was 
man vorhatte, es gab keine Software und die Leute vor den Termi¬ 
nals waren schlecht informiert und lausige Programmieren Das ist 
kein Werturteii, sondern ein Ruckblick auf die 1980'er Jahre. 

Und was fur LISP gilt das gilt auch fur Forth. Forth ist lediglich stark¬ 
er auf die Maschinenebene hin zugeschnitten. Will man darin groBere 
Programme schreiben funktioniert es ahnlich wie bei LISP auch. Aber 


warum genau hat sich beides nicht durchsetzen konnen, warum ste- 
hen die LISP Maschinen heute in einem Museum? Zunachst einmal 
nutzt die Programmiersprache gar nichts, wenn der Arbeitsspeicher 
zu klein ist. Installiert man auf einem Commodore 64 einen LISP In¬ 
terpreter hat man in der Theorie einen leistungsfahigen Fleimcomput- 
er der 5. Computergeneration der optmal geeignet ist zu Robotiks- 
teuerung und fur komplexes Theorembeweisen, doch faktisch hat man 
nicht mehr als 40 kb freien Arbeitsspeicher und wenn man dort zwei 
Seiten eintippt gibt es einen Stackoverflow. 

Das zweite Problem mit LISP ist, dass es zwar eine elgante Pro¬ 
grammiersprache ist, die selbstverstanlich Metaprogrammierung, das 
Parsen von weiteren Sprachen und sogar Objektorientierung unter- 
stutzt nur reicht das leider nicht. Benotigt man ernsthafte Anwendun- 
gen kommt es nicht auf Sprachfeatures an sondern auf die Menge 
an Codezeilen. Der Rechner nutzt gar nichts, wenn man begleit- 
end kein Software-Entwicklungsteam hat was ihn programmiert. Die 
Machtigkeit von Computern definiert sich nicht aus der Maschine selb¬ 
st sondern was die Gesellschaft darumherum erfindet. Microsoft ist 
ein Beispiel dafiir, oder LibraOffice. Beides sind keine Programmier- 
sprachen sondern es sind Organisationen die Software entwickeln. 
Man kann es wie folgt zuzusammenfassen. Die Programmiersprche 
BASIC gilt als hoffnungslos. Die Sprache unterstutzt weder Proze- 
duren und lauft extrem langsam. Aber, wurde man urn BASIC herum 
eine Softwareindustrie aufbauen wo 10000 Programmierer Code en¬ 
twickeln konnte man in BASIC leistungsfahige CAD Anwendungen, 
Robotik-Steuerungen und Bilderkennung realisieren. Das wurde zwar 
nie gemacht, stattdessen wurde das Okosystem urn C/C++ herum 
errichtet weil diese Sprachen als effizienter gelten, aber worum es 
geht ist, dass Computer und Programmiersprachen nur ein Medium 
sind was erstnoch befullt werden muss. 

Und nicht viel anders ist es mit Forth. Forth ist eine Art von Metapro- 
grammiersprache. Also ein System mit dem man andere Program¬ 
miersprache und andere Betriebssysteme entwickeln kann. Ein sehr 
leistungsfahiges Metasystem sogar. Nur leider reicht das nicht aus. 
Die Grenze von Forth wird weniger durch die MIPS Zahl der CPU 
bestimmt, sondern durch den verfugbaren Sourcecode. Wenn man 
keine Firmen findet, die Software fur Forth programmieren nutzt die 
Sprache gar nichts. Forth selber ist nicht tod, aber die Community 
darum herum. Damit ist gemeint, dass es keine Firmen gibt, die in 
Forth Betriebssysteme erstelien oder Datenbanken programmieren. 

Fruher war das einmal anders. In den 1980’er war zusammen mit 
LISP die Blutezeit von Forth. Damit ist gemeint, dass in dieser Zeit 
noch nicht klar war, welche Sprachen sich einmal durchsetzen wer¬ 
den. n den 1980’er wurden Forth und C gleichberechtigt diskutiert. 
Der Grund war, dass es damals generell keine Softwarefirmen gab. 
Software wurde damals nur an Universitaten programmiert und dort 
in LISP, Forth und ahnlichen Sprachen. 

Im Jahr 1976 hat Bild Gates einen Brief geschrieben. Er hat darin 
keine neue Programmiersprache angekundigt und auch kein Betrieb- 
ssystem. Sondern Bill Gates forderte in dem Brief die Flackercom- 
munity auf, fur Software Geld zu bezahlen. Diese Ideologie war die 
eigentliche Technologie welche die Informatik vorangebracht hat. Es 
geht nicht so sehr darum, den Flauptspeicher zu organisieren oder 
LISP Code zu schreiben sondern worum es geht ist Business. Al¬ 
so Leute anzustellen die Code schreiben und Firmen zu grunden 
die daraus ein Produkt machen. Machmal wird Bill Gates als Gegen- 
spieler zur OpenSource Bewegung gesehen. Aber das ist nicht wahr. 
Eigentlich ist das Geschaftsmodell von Red hat und das von Microsoft 
sehr ahnlich. Der Unterschied ist nur, dass bei Red Flat alles verkauft 
wird inkl. dem Sourcecode. An der Idee, Software als Business zu 
betreiben hat sich nichts geandern. 

Manchmal wird gesagt, man konnte auf einer LISP Maschine Soft¬ 
ware entwickeln. Nach dem Einschalten gibt es eine GUI mitsamt 
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Emacs Texteditor zu sehen. Genau genommen ist die LISP Maschine 
jedoch wertlos. Sie ist vergleichbar mit einer leeren Filmrolle. Um Soft¬ 
ware zu entwickeln braucht man Programmierer. Eigentlich braucht 
man nichts anderes als Programmierer, auf eine LISP Maschine kann 
man zur Not auch verzichten. Bei Microsoft arbeitet man beispiel- 
sweise nicht mit LISP Maschinen sondern mit etwas anderem und 
entwickelt auch Software. Was man eigentlich benotigt ist eine Com¬ 
munity. Also Leute die sich zusammenschlieGen und Code schreiben. 
Man kann das auf Basis von LISP tun aber auch mit C++, C# Oder 
sonstwie. 

Die entscheidene Einsicht lautet, dass Metaprogramming nicht 
funktioniert. Metaprogramming ist ein Konzept aus den 1970’er 
wonach Software sich von alleine programmiert. Das man also ein 
Programm schreibt was aus 1000 Zeilen Code besteht und das 
erzeugt dann ein Programm was 10000 Zeilen lang ist. Warum 
Metaprogramming damals als Vision gehandelt wurde hat etwas mit 
der Computergeschichte zu tun. Genau gesagt, waren die ersten 
Compiler und Hochsprachen Metaprogrammier-Tools. Man hat folglich 
geglaubt, dass man damit insgesamt Software entwickeln konnte. Das 
war ein Irrtum. Als hochste Form der Programmiersprachen gelten 
Sprachen wie C++, also objektorientierte Sprache. Eine Abstraktion- 
sstufe hoher geht es nicht mehr. Es gibt nichts womit man das Pro- 
grammieren drastisch erleichtern kann. Und man kann sogar C++ 
durch ein simples C ersetzen ohne dass die Produktitat stark leidet. 
Nur, ein Compiler alleine ist noch kein Programm, nur wenn man Pro¬ 
grammierer findet die damit Code schreiben kann man die Systeme 
hochskalieren. Also mit dem Computer Spiele spielen, Zahlen verwal- 
ten oder Roboter steuern. 

Und genau hier kommt die Vision von JCR Licklider ins Spiel. Er 
hat relativ fruh erkannt, dass Kunstliche Intelligenz grenzen hat. Man 
kann zwar in Software definieren wie man ein Fortran Programm in 
Assemblycode umwandelt aber man kann nicht in Software vorgeben 
wie man Bilder malt oder eigene Programme schreibt. Was man tun 
kann ist den Computer ais Medium zur Vernetzung zu verwenden. 
Also uber das Internet die Programmierer zusammenbringen damit 
die dann Code schreiben. Das ist keine richtige Kunstliche Intelligenz 
sondern es ist computerunterstutztes Programmieren. 
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